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FINANCIAL MANAGEMENT AT THE DEPART- 
MENT OF HEALTH AND HUMAN SERVICES 


THURSDAY, SEPTEMBER 30, 2004 

House of Representatives, 

Subcommittee on Government Efficiency and 

Financial Management, 
Committee on Government Reform, 

Washington, DC. 

The subcommittee met, pursuant to notice, at 2 p.m., in room 
2247, Rayburn House Office Building, Hon. Todd Russell Platts 
(chairman of the subcommittee) presiding. 

Present: Representatives Platts and Turner. 

Staff present: Mike Hettinger, staff director; Larry Brady and 
Tabetha Mueller, professional staff members; Nathaniel Berry, 
clerk; Adam Bordes, minority professional staff member; and Jean 
Gosa, minority assistant clerk. 

Mr. Platts. This hearing of the Subcommittee on Government 
Efficiency and Financial Management will come to order. 

Today’s hearing continues the subcommittee’s oversight of Fed- 
eral financial management and focuses on one of the most impor- 
tant building blocks for success: financial system implementation. 

The clear goal of management reforms passed over the past two 
decades is timely, accurate, useful information, financial data that 
can be used to manage and make decisions. Without this informa- 
tion, the Federal Government cannot analyze costs and benefits or 
gather an accurate assessment of program performance. In our 
oversight we have seen time and time again the importance of fi- 
nancial system implementation and how Federal agencies must 
construct the proper framework to achieve the goal of sound man- 
agement. 

As part of our oversight of these system implementations, we re- 
quested that the Government Accountability Office review the 
multi-year effort now underway at the Department of Health and 
Human Services to implement the Unified Financial Management 
System. The UFMS implementation is critical to the Government’s 
delivery of vital services to millions of citizens, and we look forward 
to discussing both the progress that has been made and the con- 
cerns that have been raised regarding this implementation. 

We are honored here today to have Jeff Steinhoff, Managing Di- 
rector of Financial Management and Assurance at the Government 
Accountability Office. He is joined by Keith Rhodes, Chief Tech- 
nologist at the GAO Center for Technology and Engineering. We 
also have Kerry Weems, Acting Assistant Secretary for Budget, In- 
formation, and Finance at the Department of Health and Human 

( 1 ) 
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Services before us today. We are glad to have you back as well, and 
have your knowledge as a panel shared with us again today. 

Mr. Towns is not going to be able to join us today. So we are 
going to move forward right into your opening statements. As a 
practice of the full committee and this subcommittee, if we can 
have you rise, I will swear you in and we can get started. 

[Witnesses sworn.] 

Mr. Platts. Thank you. The clerk will note that all witnesses af- 
firmed the oath. 

We appreciate the written testimony you have provided to give 
us a chance to prepare for today’s hearing. As far as your opening 
statements, if we can roughly be guided by 5 to 10 minutes, we are 
not going to be real sticklers because it is just more of an intimate 
dialog here today. 

Mr. Steinhoff, if you would like to begin, then we will proceed to 
Mr. Weems. 

STATEMENTS OF JEFFREY C. STEINHOFF, MANAGING DIREC- 
TOR, FINANCIAL MANAGEMENT AND ASSURANCE, GOVERN- 
MENT ACCOUNTABILITY OFFICE; KEITH A. RHODES, CHIEF 
TECHNOLOGIST, CENTER FOR TECHNOLOGY AND ENGI- 
NEERING, GOVERNMENT ACCOUNTABILITY OFFICE; AND 
KE RRY N. WEEMS, ACTING ASSISTANT SECRETARY FOR 
BUDGET, INFORMATION, AND FINANCE, DEPARTMENT OF 
HEALTH AND HUMAN SERVICES 

Mr. Steinhoff. Thank you very much, Mr. Chairman. It is a 
pleasure to be here today to discuss HHS’ efforts to implement a 
Unified Financial Management System. At the outset, I want to 
thank you for the leadership you and this subcommittee have pro- 
vided over your tenure to really move financial management ahead. 
This is very important. The challenges that HHS is facing, as well 
as the other CFO agencies, in working on difficult systems issues 
really require oversight and understanding by the Congress. So, 
thank you for all of your efforts. 

The report we are releasing at today’s hearing, which was pre- 
pared at your request, includes 34 recommendations that focus on 
mitigating the risks associated with this project. For eight of these 
recommendations in particular, we recommended that until they 
are substantially addressed, HHS should delay the October 1st 
planned deployment of the new system at CDC. As you will hear 
today, they have, in fact, done that. 

The core concepts and goals of financial management are cap- 
tured well in the 1990 CFO Act. At the heart of the act are three 
provisions that require, first, the systematic measurement of per- 
formance; second, the development of cost information; and third, 
the integration of systems, program budget, and financial. Good fi- 
nancial management is having reliable, useful, and timely informa- 
tion needed for day to day decisionmaking and management. This 
requires first rate financial management systems that go far be- 
yond core accounting and financial statement preparation. The sys- 
tems must address the broader concepts imbedded in the CFO Act 
and addressed in the President’s Management Agenda which is 
moving us toward a business-centric Government. 
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We support HHS’ decision to replace its five outdated accounting 
systems. We are not questioning whether a new system is needed 
or HHS’ commitment to making this happen. Our work focused on 
whether the project was being managed in a way that best ensures 
long-term success. This is a major project. All projects are difficult; 
a major project, you multiply that several-fold. Full implementation 
is targeted for 2007, so there is a lot of time to address issues, and 
the estimated cost of this project is around $700 million. Not only 
must the system ultimately replace five accounting systems, but it 
must also interface with about 110 other systems. 

When all is said and done, how does one define success? In 2007, 
in addition to basic accounting and financial reporting, we think of 
it in terms of three results. First, a system that routinely provides 
the day to day management information envisioned by the CFO Act 
and the President’s Management Agenda; second, a system that op- 
erates efficiently, meaning, it does not require a whole lot of man- 
ual processing to make up for shortfalls in design or implementa- 
tion; and third, a system that does not require expensive rework. 
All systems require some. The real goal is to control any rework. 

By any measure, the implementation of a new information sys- 
tem, whether in Government or the private sector, this is not a 
government-centric issue, is difficult and brings with it a degree of 
risk. As I said before, for a major project the risk is much greater. 
While risk cannot be avoided, it can be managed and reduced to 
acceptable levels through the use of disciplined processes, which, in 
short, represent best practices that have proven their value in the 
past. 

Our experience is that serious implementation problems are gen- 
erally the result of not effectively implementing disciplined proc- 
esses. It is easy to forego, shortcut, or delay key steps, especially 
when your project is date-driven; you have pressures to meet 
schedule, to meet budget. We have seen this in our work at other 
agencies and it has had serious repercussions for them. 

At HHS we found that some best practices were adopted. For ex- 
ample, the project had strong support of senior officials, as well as 
verification and validation oversight by independent experts, com- 
monly called IV&V. We also view HHS’ decision to follow a phased 
implementation to be a sound approach. 

At the same time, at the time of our review, the project dem- 
onstrated some of the classic symptoms of schedule-driven efforts 
for which disciplined processes, such as requirements management, 
and testing had not yet been effectively implemented. In addition, 
compounding the project-specific risks were department-wide weak- 
nesses in information technology management, enterprise architec- 
ture, and information security. Finally, staff shortages and limited 
strategic work force planning resulted in the project not always 
having the needed resources. 

For these reasons, we concluded that HHS had not yet reduced 
its risk to an acceptable level. Among our 34 recommendations, as 
I mentioned at the outset, we called for HHS to delay deployment 
at CDC until certain actions had been completed to reduce the risk 
to an acceptable level. Last week, HHS advised us that it had de- 
cided to defer full deployment of the system at CDC for 6 months. 
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This additional time provides HHS the opportunity to address our 
concerns as well as similar concerns raised by its IV&V contractor. 

Keith Rhodes will now highlight what we think are some of the 
things that need to be done, and done now, to take full advantage 
of this 6 month period. He will focus on four key areas. 

Mr. Rhodes. Thank you, Mr. Chairman. HHS will face a number 
of challenges in the upcoming 6 months. The key challenge being, 
as Mr. Steinhoff stated, to move from a schedule-driven project to 
an event-driven project. This will be critical to address problems 
that both we in GAO and the IV&V contractor have identified. I 
will focus my comments on four areas: First, requirements manage- 
ment; second, testing; third, quantitative measures; and fourth, 
data conversion and interfaces. 

We view requirement managements and testing as two of the pil- 
lars of successful efforts, while quantitative measures are critical 
to understand the risks that are being undertaken and whether the 
project is ready for deployment. Finally, good data conversion and 
interfaces are critical to being able to provide the kind of manage- 
ment information that will be needed to meet the goals of the CFO 
Act and the President’s Management Agenda. 

Regarding requirements, requirements must one, describe the 
functionality needed to meet user needs; two, be defined in a way 
that is clear and unambiguous; and three, support an effective test- 
ing process, meaning that compliance with the requirement can be 
validated through quantitative means. Once you have the good re- 
quirements, HHS will be in a position to conduct effective testing 
activities. 

The foundation of an effective testing program is a documented 
testing plan that describes how testing will be carried out and con- 
trolled. For example, HHS will need to implement effective func- 
tional testing and user acceptance testing which will enable HHS 
to know what the system can and cannot do, and whether the sys- 
tem meets the users’ needs, including being user friendly. In the 
private sector, you are doing the user acceptance testing to figure 
out what the take-up of the system is going to be. 

Quantitative measures. HHS will need to use quantitative meas- 
ures to evaluate the success of the events that are used to measure 
project progress in order to help ensure that it is adopting event- 
driven processes. Without reliable and rigorous quantitative meas- 
ures, it is impossible to see where you are on the playing field. In- 
tuitively, you might think that you are moving ahead and making 
progress. But how far and in what direction is the bigger question. 

Finally, HHS’ ability to convert data from its legacy systems to 
the new system will be critical to the success of the project, as will 
the ability to interface the system with, as Mr. Steinhoff stated, 
110 other information systems that support key functionality, such 
as grant accounting. For example, HHS expects that UFMS will 
need to support about 30 system interfaces for the CDC deploy- 
ment alone. 

This does not mean that by successfully addressing these four 
areas alone HHS will have reduced its risks to acceptable levels. 
Rather, relatively speaking, we view these areas as being critical 
and needing to be fully addressed between now and the planned 
April 2005 full deployment. 
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In closing, if the past is prologue, taking the time to effectively 
implement the disciplined processes discussed in our report and 
called for by HHS’ IV&V contractor will pay long-term dividends, 
and to do otherwise has proven to be counter-productive and costly 
in the long term. 

Mr. Chairman, this concludes our summary comments. We would 
be pleased to respond to any questions that you may have. 

[The prepared statement of Mr. Steinhoff and Mr. Rhodes fol- 
lows:] 
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FINANCIAL MANAGEMENT SYSTEMS 

HHS Faces Many Challenges in 
Implementing its Unified Financial 
Management System 


What GAO Found 

HHS had not effectively implemented several disciplined processes, which 
are accepted best practices in systems developm ent and implementation, 
and had adopted other practices, that put the project at unnecessary risk. 
Although the implementation of any m^or ^tem is not a risk-free 
proposition, oi^anlzalions tihat follow and effectively implement disciplined 
processes can reduce these risks to acceptable levels. While GAO recognized 
that HHS had adopted some best practices related to senior level support, 
oversight, and phased implementation, GAO noted that HHS had focused on 
meeting its schedule to the detriment of disciplined processes. 

GAO found that HHS had not effectively implemented several disciplined 
processes to reduce risks to acceptable levels, including 

• requirements management, 

• testing, 

• project mani^ement and oversight using quantitative measures, and 

• risk management 

Compounding these problems are departmentwide weaknesses in 
information technology management processes needed to provide UFMS 
with a solid foimdation for development and operation, including 

• inve^ment management, 

• enterprise architecture, and 

• inform^on security. 

GAO also identlTied human capita] issues that significantly increase the risk 
that UFMS will not ftilly meet one or more of its cost, schedule, and 
performance objectives, including 

• staffing and 

• strategic workforce planning. 

HHS stated that it had an aggressive implementation schedule, but disagreed 
that a lack of disciplined processes is placing the UFMS program at risk, 

GAO firmly believes if HHS continues to follow an ^proach that is 
schedule-driven mid shortcuts key disciplined processes, it is unnecessarily 
increasing its risk. GAO stands by its position that adherence to disciplined 
processes is crucial, particularly with a project of this magnitude and 
importance. 

HHS indicated that it plans to delay deployment of significant functionality 
associated with its UFMS project for at least 6 months. This decision gives 
HHS a good opportunity to effectively implement disciplined processes to 
enhance the project’s opportunity for success. 


.United Stales Government Accountability Office 
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Mr. Chairman and Members of the Subcommittee; 

We are pleased to be here today to discuss the efforts by the Department of 
Health and Human Services (HHS) to develop and implement its Unified 
Financial Management System (UFMS). We would like to thank the 
Subcommittee for having this hearing. Hearings such as this one today 
foster meaningful financial management reform. Our work focused on 
whether the UFMS project was being managed in a way that best ensures 
long-tenn success of this important project. At the time of our review, the 
complete implementation of UF^ was targeted for 2007 and the estimated 
total project cost was over $700 million. ’ Not only must the system 
ultimatdy replace 5 accounting systems, but it must also interface with 
about ilO other systems. By any measure, this is a m^or undertaking that 
brings with it a degree of risk. Risk, though, can be managed and reduced 
to acceptable levels through the use of disciplined processes, which in 
short, represent best practices in system development and implementation 
that have proven their value in the past. 

Our report,^ which was prepared at the request of the Subcommittee and is 
being released at this hearing, discusses in detail the issues we identified 
with the UFMS project and includes 34 recommendations that focus on 
mitigating project risk. Our testimony today^ will (1) highlight the 
importance of adhering to disciplined processes for a system development 
and implementation effort such as UFMS, (2) summarize our findings on 
HHS’ management of the UFMS project, and (3) provide our perspective on 
actions needed for HHS to mitigate the risk to this project and move 
forward. 


'The coas for this finaiiciai management system improvement effort can be broken down 
into four broad areas: ( 1) National Institutes of Health (NIH); (2) Centers for Medicare and 
Medicaid Services (CMS); (3) all other HHS entities including liie Centers for Disease 
Control and Prevention (CDC); and (4) a system to consolidate tlie results of HHS’ financial 
management operations. HHS estimated that it would spend about ?] 10 million for NIH, 
^93 million for CMS, and $210 million few the remaining HHS organizations. HHS has not 
yet developed an estimate of the costs associated with integrating tht^se efforts into a 
unified financial management system. 

'^GAO, Financial Management Systems: Lack of Disciplined Processes Puts 
Implementalion of I IKS’ Financial System at Risk, GAO-04-1008 (Washington, D.C.; 

!^pl, 23, 2004). 


*rhis testimony is based on our report and does not assess HHS’ other financial 
management improvement efforts at the National Institutes of Healtli (NIH) and Centers for 
Medicare and Medicaid Services (CMS). 
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Disciplined Processes 
Are Key to Successful 
System 

Implementation 


The to produce the information needed to efficiently and effectively 
manage the day-to-day operations of the federal government and provide 
account^ility to taxpayers and the Congress has been a long-standing 
challenge for federal agencies. To help address this challenge, many 
agencies are in the process of replacing their core financial systems as part 
of their financial man^ement system improvement efforts. Although the 
implementation of any major system is not a risk-free proposition, 
organizations that follow and effectively implement disciplined processes 
can reduce th^e risks to acceptable levels. The use of the term acceptable 
levels acknowledges the f^t that any systems acquisition has risks and will 
suffer the adveise consequences associated with defects. However, 
effective implementation of the disciplined processes reduces the potential 
for riste to occur and helps prevent those that do occur from having any 
significant adverse impact on the cost, timeliness, and performance of the 
project. A disciplined software development and acquisition process can 
maximize the likelihood of achieving the intended results (performance) 
within established resources (costs) on schedule. 


Although there is no standard set of practices that will ever guarantee 
success, several organizations, such as the Software Engineering Institute 
(SEI)*' and the Institute of Electrical and Electronic Engineers (IEEE),® as 
well as individual experts have identified and developed the types of 
policies, procedures, and practices that have been demonstrated to reduce 
development time and enhance effectiveness. The key to having a 
disciplined system development effort is to have disciplined processes in 
multiple areas, including project planning and management, requirements 
management, configuration management, risk management, quality 
assurance, and testing. Effective processes should be implemented in each 
of these areas throughout the project life cycle because change is constant. 
Effectively implementing the disciplined processes necessary to reduce 
project risks to acceptable levels is hard to achieve because a project must 
effectively implement several best practices, and inadequate 


'SEI is a federally funded research and devoiopmeni center operated by (’amegie Mellon 
Univcrelly and sponsored by the U S. Department of Defense. The SEI objectives are to 
provide leadership in software engineering and in the transition of now software 
engineering technologies it>U) practice. 

’IEEE develc^s standards for a broad range of global Industries inchiding the information 
technology and information assurance industries. 
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implementation of any one practice may significantly reduce or even 
eliminate the positive benefits of the others. 

Successfully acquiring and implementing a new financial management 
system requires a proems that starts with a clear definition of the 
organization’s minion md strategic objectives and ends with a system that 
meets specific information needs. We have seen many system efforts fail 
because agencies started with a general need, such as improvuig financial 
management, but did not define in precise terms (1) the specific problems 
they were trying to solve, (2) what their operational needs were, and 
(3) what specific infonnjdion requirements flowed from these operational 
needs. Instead, they plunged into the acquisition and implementation 
process in the belief that these ^ecifics would somehow be defined along 
the way. The typical result was that systems were delivered well past 
anticipated milestones; failed to perform as expected; and, accordingly, 
were overbudget because of required costly modifications. 

Undisciplined projects typically show a great deal of productive work at 
the beginning of the project, but the rework associated with defects begins 
to consume more and more resources.* In response, processes are adopted 
in the hopes of managing what later turns out to have been unproductive 
work. Generally, these processes are “too little, too late” because sufficient 
foundations for building the systems were not established or not 
established adequately. Experience has shown that projects for which 
disciplined processes are not implemented at the beginning are forced to 
implement them later when it takes more time and the processes are less 
effective.’ 

A major consumer of project resources in undisciplined efforts is rework 
(also known as thrashing). Rework occurs when the original work has 
defects or is no longer needed because of changes in project direction. 
Disciplined organizations focus Uieir efforts on reducing the amount of 
rework because it is expensive. Experts have reported that fixing a defect 
during the testing phase costs anywhere from 10 to 100 times the cost of 
fixing it during the design or requirements phase.® Projects that are unable 


•Steve McConnell, Sapid Zieveiopment, Thmitig Wild Software Schedules (Redmond, Wash.; 
Microsoft Press, 1996). 

'McConnel!, Rapid Developmeni: Thming Wild Software Schedules. 

•iWcConne!!, Rapid Developm,ent: Thming Wild Software Schedules. 
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to succ^rfuUy ^dress their rework will eventually only be spending their 
time on rework and the associated processes rather than on productive 
work. In other words, the project will continually find itself reworking 
items. 


HHS Had Not 
Effectively 
Implemented 
Disciplined Processes, 
Information 
Technology 
Management Practices, 
and Human Capital 
Planning 


We found that HHS had adopted some best practices in its development of 
UFMS. The project had support from senior officials and oversight by 
independent experts, commonly called independent verification and 
validation (IV&V) contractors. We also view HHS’ decision to follow a 
phased implementation to be a sound approach. 

However, at the time of our review, HHS had not effectively implemented 
several disciplined processes essential to reducing risks to acceptable 
levels and therefore key to a project’s success, and had adopted other 
practice that put the project at unnecessary risk. HHS officials told us that 
they h^ carefully considered the risks associated with implementing 
UFMS and that they had put in place strategies to manage these risks and to 
allow the project to meet its schedule within budget. However, we found 
that HHS had focused on meeting its schedule to implement the first phase 
of the new system at the Centers for Disease Control and Prevention (CDC) 
in October 2004, to the detriment of disciplined processes and thus had 
introduced unnecessary risks that may compromise the system’s cost, 
schedule, and performance. We would now like to briefly highlight a few of 
the key disciplined processes that HHS had not fully implemented at the 
time of our review. These matters are discussed in detail in our report. 


♦ Requirements management. Requirements are the specifications that 
system developers and program managers use to design, develop, and 
acquire a system. Requirements management deficiencies have 
historically been a root cause of systems that do not meet their cost, 
schedule, and performance objectives. Effective requirements 
management practices are essential for ensuring the intended 
functionality will be included in the system and are the foundation for 
testing. We found significant problems in HHS’ requirements 
management process and that HHS had not developed requirements that 
were clear and unambiguous. 


Pagp 4 
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• Testing. Testing ^ the process of executing a program with the Intent of 
finding errors.® WiUtout adequate testing, an organization (1) is taking a 
significant risk that substantial defects will not be detected until after 
the sj^tem is implemented and (2) does not have reasonable assurance 
that new or modified systems will function as planned.- We found that 
HHS faced challenges in implementing a disciplined testing program, 
because, first of all, it did not have an effective requirements 
man^ement s:^tem that produced clear, unambiguous requirements 
upon which to build its testirig efforts. In addition, HHS had scheduled 
its testing activities, including those for converting data from existing 
systems to UFMS, late in the implementation cycle leaving little time to 
correct defects identified before the scheduled deployment in October 
2004. 

• Project management and oversight using quantitative measures. We 
found that HHS did not have quantitative metrics that allowed it to fully 
understand (I) its capability to manage the entire UFMS effort; (2) how 
problems in its management processes would affect the UFMS cost, 
schedule, and performance objectives; and (3) the corrective actions 
needed to reduce the risks associated with the problems identified with 
its processes. Such quantitative measures are essential for adequate 
project management oversight. Without such information, HHS 
management can only focus on the project schedule and whether 
activities have occurred as planned, not on whether the substance of the 
activities achieved their system development objectives. As we note in 
our report, this is not an effective practice. 

• Risk management. We noted that HHS routinely closed its identified 
risks on the premise that they were being addressed. Risk management 
is a continuous process to identify, monitor, and mitigate risks to ensure 
that the risks are being properly controlled and that new risks are 
identified and resolved as early as possible. An effective risk 
management process is designed to mitigate the effects of undesirable 
events at the earliest possible stage to avoid costly consequences. 

In addition, HHS’ effectiveness in managing the processes associated with 
its dam conversion and UFMS interfaces will be critical to the success of 
this project. For example, CDG’s ability to convert data from its existing 
systems to the new system will be crucial to helping ensure that UFMS will 
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provide the kind of dataneeded to manage CDC’s programs and operations. 
The adage “garbage in garbage out” best describes the adverse impact. 
Furthermore, HHS expects that once UFMS is fully deployed, the system 
will need to interface with about 1 10 other systems, of which about 30 
system interfeces are needed for the CDC deployment. Proper 
implementation of ttie interfaces between UFMS and the other systems it 
receives data from and sends data to is essential for providing data integrity 
and ensuring that UFMS wiil operate as it should and provide the 
information needed to help manage its programs and operations. 

Compounding these UFMS-specific problems are departmentwide 
weaknesses we have previously reported in infonnation technology (IT) 
investment management, “ enterprise architecture," and information 
security.'^ Specifically, HHS had not established the IT management 
processes needed to provide UFMS with a solid foundation for 
development and operation. Such IT weaknesses increase the risk that 
UFMS will not achieve planned results within the estimated budget and 
schedule. We will now highlight the IT management weaknesses that HHS 
must overcome: 

• Investment management. HHS had weaknesses in the processes it uses 
to select and control its IT investments. Among the weaknesses we 
previously identified, HHS had not (1) established procedures for the 
development, documentation, ai\d review of IT investments by its 
review boards or (2) documented policies and procedures for aligning 
and coordinating investment decision making among Its investment 
management boards. Until HHS addresses weaknesses in its selection or 
control processes, IT projects like UFMS will face an increased 
likelihood that the projects will not be completed on schedule and 
within estimated costs. 

• Enterprise architecture. While HHS is making progress in developing an 
enterprise architecture that incorporates UFMS as a central component, 


’“GAO, Information Technology ManagemenL- Gmiemmentwide Strategic Planning, 
Performance Measurement, and Investment Management Can lie Further Improved, 
GAO-04-49 (Washington, D.C.: 12, 2004). 

"GAO, Information Technology: Leadership Remains Key to Agencies Making Progress on 
Enterprise Arehileclure Efforts, GAO-O4-40 (Washington, D.C.; Nov. 17, 2003). 

'-GAO, Information Security: Agencies Need to Implement Consistent Processes in 
Authorizing Systems for Opmition, GAO-04-376 (Washington, D.C.; Jiinf* 2004). 
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most of the pluming and development of the UFMS IT investment had 
occurred without the guidance of an established enterprise architecture. 
An enterprise architecture is an organizational blueprint that defines 
how an entity operates today and how it intends to operate in the future 
and inv^t in technology to transition to this future state. Our 
experience with other federal agencies has shown that projects 
developed without the constraints of an established enterprise 
architecture are at risk of being duplicative, not well integrated, 
unnece^arily costly to maintain and interface, and ineffective in 
supporting missions. 

• Information security. HHS had not yet fully implemented the key 
elements of a comprehensive security management program and had 
significant and pervasive weaknesses in its information security 
controls. The primaiy objectives of information security controls are to 
safeguard data, protect computer application programs, prevent 
unauthorized access to system software, and ensure continued 
operations. Without adequate security controls, UFMS cannot provide 
reasonable assurance that the system is protected from loss due to 
errors, fraud and other illegal acts, disasters, and incidents that cause 
systems to be unavailable. 

Finally, we believe it is essential that an agency take the necessary steps to 
ensure that it has the human capital capacity to design, implement, and 
operate a financial management system. We found that staff shortages and 
limited strategic workforce pianning have resulted in the project not having 
the resources needed to effectively design, implement, and operate UFMS. 
We identified the following weaknesses: 

• Staffing. HHS had not filled positions in the UFMS Program 
Management Office that were identified as needed. Proper human 
capital planning includes identifying the workforce size, skills mix, and 
deployment needed for mission accomplishment and to create 
strategies to fill tlie gaps. Scarce resources could significantly 
jeopardize the project’s success and have led to several key UFMS 
deliverables being significantly beliind schedule. 

• Strategic workforce planning. HHS had not yet fully developed key 
workforce planning tools, such as the CDC skills gap analysis, to help 
transform its workforce so that it can effectively use UFMS. Strategic 
workforce planning focuses on developing long-term strategies for 
acquiring, developing, and retaining an organization’s total workforce 
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(including foil- and part-time federal staff and contractors) to meet the 
needs of the future. Strategic workforce planning is essential for 
achieving the mission and goals of the UFMS project. By not identifying 
staff with the requisite skife to operate such a system and by not 
identifying gaps in needed skills and filling them, HHS has not optimized 
its chances for the successful implementation and operation of UFMS. 


Action Is Needed to address the range of problems we have just highlighted, our report 

AyT’+' 1 - T?* 1 includes 34 recommendations that focus on mitigating the risks associated 

iVllLlgnte XtlSK project We made 8 recommendations related to the initial 

deployment of UFMS at CDC that are specifically tied to implementing 
critical disciplined processes. In addition, we recommended that until 
these 8 recommendations are substantially addressed, HHS delay the initial 
deployment. The remaining 25 recommendations were centered on 
developing an appropriate foundation for moving forward and focused on 
(1) disciplined processes, (2) FT security controls, and (3) human capital 
issues. 

In its September 7, 2004, response to a draft of our report, HHS disagreed 
regarding management of the project and whether disciplined processes 
were being followed. In its comments, HHS characterized the risk in its 
approach as the result, not of a lack of disciplined processes, but of an 
aggressive project schedule. From our perspective, this project 
demonstrated the classic symptoms of a schedule-driven effort for which 
key processes had been omitted or shortcutted, thereby unnecessarily 
Increasing risk. As we mentioned at the outset of our testimony, this is a 
multiyear project with an estimated completion date in fiscal year 2007 and 
a total estimated cost of over $700 million.'® With a project of this 
magnitude and importance, we stand by our position that it Is crucial for 
the project to adhere to disciplined processes that represent best practices. 
Therefore, in order to mitigate its risk to an acceptable level, we continue 
to believe it is essential for HHS to adopt and effectively implement our 34 
recommendations. 

In commenting on our draft report, HHS also indicated that actions had 
either been taken, were under way, or were planned that address a number 
of our recommendations. In addition, HHS subsequently contacted us on 
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September 23, 2004, to let us know that it had decided to deiay the 
implementation of a significant amount of functionality dissociated with the 
CDC deployment from October 2004 until April 2005 in order to address the 
issues that had been identified with the project. HHS also provided us with 
copies of IV&V reports and other documentation that had been developed 
since our review. Delaying implementation of significant functionality at 
CDC is a positive step forward given the risks associated with the project. 
This delay, by itself, will not reduce the risk to an acceptable level, but will 
give HHS a chance to inyilement the disciplined processes needed to do so. 

HHS will face a number of challenges in the upcoming 6 months to address 
the weaknesses in its management of the project that were discussed in our 
report At a high level, the key challenge will be to implement an event 
driven project based on effectively implemented disciplined processes, 
rather than a schedule-driven project. It will be critical as well to address 
the problems noted in the IV&V reports that were issued during and 
subsequent to our review. If the past is prologue, taking the time to adhere 
to disciplined processes will pay dividends in the long term. 


Mr. Chairman, tliis concludes our statement. We would be pleased to 
answer any questions you or other members of the Subcommittee may 
have at this time. 
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Mr. Platts. Thank you, Mr. Steinhoff and Mr. Rhodes. 

Mr. Weems. 

Mr. Weems. Mr. Chairman, thank you for the opportunity to ap- 
pear before you today. It is probably rare that somebody sincerely 
thanks the subcommittee when asked to appear in response to a 
GAO report. However, I believe we have a strong story to tell, so 
my thanks are sincere. I am here to discuss the HHS Unified Fi- 
nancial Management System. When completed in 2007, we believe 
it will be the largest integrated financial management system in 
the world. 

In 2001, HHS was engaged in replanning and budgeting for our 
five major financial management systems. Secretary Thompson, be- 
lieving that current technologies would allow for consolidation of 
the five systems into a single system, producing lower cost and bet- 
ter financial outcomes, challenged us to plan, procure, and imple- 
ment a single system. I direct the committee’s attention to my first 
chart, which is a reproduction of the Secretary’s memorandum di- 
recting us to begin that endeavor. 

Looking just briefly at the goals that this memorandum looked 
for, it looked for consolidation, it looked for better management re- 
porting, and lower administrative cost. This was very early in the 
Secretary’s tenure, as you can see from the date, and this is how 
long this charge has been with us. 

To illustrate what the Secretary gave us in this charge, this next 
chart illustrates how we moved from our former decentralized envi- 
ronment to a new business intelligent shared services environment. 
Currently, Mr. Chairman, we struggle every year to be able to get 
a clean opinion because of the nature of our financial systems. We 
looked for a financial system to provide that information in an inte- 
grated way and to make that essentially a slam-dunk every year. 

We look forward to going to a shared services environment where 
a single service center can, for instance, pay bills for the entirety 
of the agency rather than having separate service centers. That is 
the vision. And also, to be able to provide us reliable, business in- 
telligent information about the direction of program activity and 
about the direction of HHS overall. 

The scope of the undertaking is breath-taking. HHS has the larg- 
est budget of any cabinet agency, projected to be nearly $580 billion 
in the fiscal year that starts tomorrow. Within that budget is an 
extremely complex array of spending arrangements, including man- 
datory spending, discretionary spending, loan programs, the Gov- 
ernment’s largest grant portfolio, single and multiple year appro- 
priations, buildings and facilities account. Medicare payments, user 
fees, revolving funds. The list goes on. The task of implementing 
a single system to manage those various business arrangements 
and to provide HHS leadership with meaningful financial informa- 
tion for decisionmaking is a monumental task. 

I am happy to report to this subcommittee that HHS has 
achieved a number of successes and stands on the cusp of achieving 
more. In doing so, I would like to acknowledge the Government Ac- 
countability Office and their efforts to better help us manage this 
undertaking. Before I review those successes with the committee, 
I would like to discuss the draft GAO report. 
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The thrust of the GAO report was that certain management 
practices increased the risk of the UFMS project, and the report 
contained a number of recommendations to mitigate the risks. HHS 
has accepted and implemented a number of those recommenda- 
tions. From our perspective, the GAO comments can be distilled 
into five main areas of concern: Requirements management and 
traceability; testing and data conversion; concept of operations; in- 
formation technology infrastructure; and project management. I 
would like to discuss each one of these in turn. 

HHS chose an off-the-shelf software package, Oracle Federal Fi- 
nancials. The effect of making such a choice is to say HHS will 
mold its business practices to the software. That is very different 
than a ground-up software development effort where all require- 
ments are identified at the finest level of detail and the new soft- 
ware is coded to meet the demands of the business practices. For 
HHS, the choice of molding our business practices to the software 
means that we can have uniformity of business practice, exactly 
what the Secretary envisioned in standardizing our business prac- 
tices across the 12 operating divisions in HHS. 

The managerial benefits of standardization are immense. A bill 
to be paid can be booked and paid exactly the same way in FDA 
as it is in CDC, or, indeed, a payment for all agencies can be made 
from a single center. Since many of the requirements are contained 
in the software, requirements can be managed at a higher level of 
granularity. 

HHS has a central repository of over 2,100 requirements for 
UFMS, which includes the requirements specified by the Joint Fi- 
nancial Management Improvement Program. Those requirements 
not met by the software underwent a business change process to 
conform business practices to Oracle Federal Financials, or, in a 
few limited instances, an extension was written for the software. 
HHS has also built a requirements traceability verification matrix 
to verify that all requirements are met by the system and to dem- 
onstrate to HHS and outside parties that we have satisfied the sys- 
tem requirements. 

At the time of GAO’s review, full test plan and test scripts were 
not available for review. So, understandably, GAO raised concern. 
Since that time, a full test plan has been developed and imple- 
mented. Testing is appropriate to Oracle Federal Financial’s ma- 
ture product. Therefore, our testing is unit testing, integration test- 
ing, and user acceptance testing. These tests focus on items such 
as interfaces developed specifically from, as I say, user and feeder 
systems. Testing continues to this day. 

As GAO notes, data conversion is a difficult task. HHS originally 
planned two mock conversions, essentially dress rehearsals for 
final data conversion. We now intend to conduct four. This dem- 
onstrates that our project management was flexible enough to ac- 
commodate difficulties outside of the plan but still stay on course. 

The GAO report urges HHS to adopt a concept of operations; that 
is, what operations must be performed, who must perform them, 
and where and how they must be performed. Our own independent 
verification and validation contractor. Titan Corp., has also urged 
us to do so. 
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In July 2002, HHS developed and adopted a target business 
model, a description of business operations and how a design of 
those operations will be performed at HHS. We believe that this 
business model provides a suitable concept of operations while 
maintaining flexibility required by our rapidly changing business 
environment, including changes to travel, acquisition, grants man- 
agement, financial management, and information technology. Let 
me give you an example. The idealized concept of operations would 
say how bills get paid in HHS and who will do it. Our business 
model has the “how” but not the “who.” 

The implementation of the unified financial management system 
will foster a significant organizational transformation for HHS, a 
department that has traditionally followed a decentralized ap- 
proach to financial management. Although this initiative relies on 
technology at its core, it is a business transformation initiative, em- 
phasizing the importance of standardization across our business 
units. 

For a number of business functions, we have asked our operating 
divisions to prepare business plans and bid to be a service provider. 
This produces internal competition for business and produces a bet- 
ter result than a pre-determined “who.” So our divisions are essen- 
tially competing to be one of the providers of the services. 

Finally, we have a governance structure, which we illustrate 
here, that allows us the flexibility to adopt our concept of oper- 
ations to changing business needs. GAO also noted our governance 
structure as a best practice, the department from top to bottom is 
heavily invested in this program, from the users of business sys- 
tems to our leadership. Changes are run through this model. Also, 
this model and this structure is used to implement other business 
changes in HHS, for instance, the recent changes that we have 
made to e-travel. Because UFMS is the central architecture to 
these things, we use this structure as a means of decisionmaking 
for those items. Users, managers, and leaders all share a voice. 

GAO noted several deficiencies in HHS information technology 
infrastructure, especially security. I am happy to report that HHS 
has greatly increased security for its systems. Right now, of the 
175 systems, 96 percent have completed a risk assessment, 95 per- 
cent have security plans, and 93 percent have been certified and 
accredited for security. Eighteen of the nineteen systems that inter- 
face with UFMS have been certified and accredited. 

As the accrediting official for UFMS, I expect to accredit UFMS 
in the next several days. UFMS will run on a new secure network 
recently implemented in HHS, called HHS-net, which is slated for 
certification and accreditation in October 2004, making 19 of 19 
systems. In fact, UFMS will be the first enterprise-wide system de- 
ployed over HHS-net. 

In the area of program management, we found a number of areas 
where we agree with GAO. We agree we were prematurely closing 
identified risks. And we have modified our risk management ac- 
cordingly. We agree that the management of human capital has 
been and continues to be a significant risk. And we agree that our 
project status monitoring could be strengthened further. 

Where we do not agree is in the overall management strategy. 
GAO believes that the project should be event-driven and the 
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project should be governed by the achievement of objectively meas- 
ured milestones. In a perfect world I would agree with GAO. How- 
ever, we are a schedule-driven project, even though that means in- 
creasing risk. 

The legend about Federal employees and Federal executives is 
that they are not risk-takers and they seek the path of least risk 
and least resistance. In HHS we are undergoing a tremendous met- 
amorphosis in the way that we do business. Our employees want 
to be very much a part of that, and my job as a manager is to har- 
ness that enthusiasm and to translate it into real outcomes for 
HHS. I believe we have succeeded. Through outreach, demonstra- 
tion, and training, there have been nearly 6,000 experiences for 
HHS employees with UFMS. Awareness and expectation exceed 
even those levels. 

So, what are the consequences of being schedule-driven? In Feb- 
ruary of this year a sober, objective, hard review of where we stood 
on GDC implementation revealed that perfect execution would be 
required to meet full implementation in October. Understanding 
the consequences of that, our team was excited because they be- 
lieved perfection to be within their reach. 

By May, our assessment was that a heroic effort would be re- 
quired, but we pressed on. For members of the team it meant work- 
days that extended to 12 or 14 hours, workweeks that extended 
into 6 days or more, and limited or no leave during this period. The 
amount of personal sacrifice on the part of our employees was tre- 
mendous. The amount of sacrifice on the part of our contractor, the 
systems integrator, BearingPoint, was tremendous also. And I am 
grateful for all of their sacrifices. 

On August 20 , I received an alert from our independent verifica- 
tion and validation contractor asking me, among other things, to 
obtain a briefing from the project team on systems readiness. I met 
with the project team here and in Atlanta and conducted a systems 
readiness review. At the conclusion of those reviews, and using ob- 
jective, quantifiable measures of readiness and completion, we de- 
cided to deploy UFMS in October for CDC and FDA. The deploy- 
ments would include general ledger and payroll for both, and 
grants for CDC later that quarter. Other functionality for CDC is 
phased to April to match that of FDA, and we have completed a 
project plan accounting for that phasing. 

In conclusion, I believe that UFMS continues to succeed. We 
were able to capture the enthusiasm and know-how of a remark- 
able group of Federal employees and contractors to complete two 
implementations of UFMS. We are proud of the milestones that we 
have achieved. The implementation at NIH will have functioned for 
a year. This year’s financial reports for NIH will come from that 
implementation. 

The October deployment of general ledger, payroll, and grants re- 
mains a tremendous accomplishment. The overall schedule for 
UFMS remains the same. We still plan to have full implementation 
across HHS by the end of 2007, a date that seems less distant all 
the time. The work that has been accomplished is valuable and has 
been preserved by the phased implementation strategy. Partici- 
pants can look back with pride on their accomplishments and for- 
ward to even more successes in the future. 
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Finally, Mr. Chairman, in the days when Federal managers are 
being urged to take risks and Federal employees are criticized as 
being risk-averse, we took a calculated risk by being schedule-driv- 
en. We believe it to have been a necessary risk and one in the best 
interest of the project. I want to publicly thank the members of the 
UFMS team across the department for their dedication and dili- 
gence. I would also like to thank GAO for their comments, and this 
committee for your oversight and for having this hearing today. 
Thank you. 

[The prepared statement of Mr. Weems follows:] 
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Introduction 

Good morning. Chairman Platts, Madam Vice-Chairman and Members of the Committee. 

I am honored to have been asked to provide testimony here today on the Department’s Unified Financial 
Management System (UFMS). Today, at your request, I will be addressing the Department’s efforts to 
develop the UFMS and respond to the Government Accountability Office's (GAO) Report, “Financial 
Management Systems: Lack of Disciplined Processes Puts Implementation of HHS' Financial System at 
Risk, GAO-04-1008.” 

In June 2001, Health & Human Services (HHS) Secretary Tommy Thompson, through an Executive 
Memorandum, directed that a unified accounting system be established for the Department of Health 
and Human Services. The Secretary wanted to achieve greater economies of scale, eliminate 
duplication, and provide better service delivery. His mandate established the Unified Financial 
Management System (UFMS) Program, which is focused upon achieving the following strategic 
objectives: 


• Eliminate redundant and outdated financial systems by implementing a modem integrated 
HHS-wide system 

• Produce accurate, timely, reliable, and relevant financial information to help HHS 
managers make fact-based decisions to improve customer service 

• Comply with applicable Federal financial management system requirements, accounting 
practices, and transaction standards 

• Strengthen internal controls by instituting standard business rules, data requirements, and 
accounting policies across HHS 

• Streamline operational activities to achieve more efficient and cost-effective business 
performance 

• Continue to achieve unqualified audit opinions on annual financial statements 
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UFMS was designed as an integrated financial system for HHS and all of its operating components. It is 
not only a vital element of Secretary Thompson’s vision of “One HHS” it is also responsive to the 
President’s Management Agenda calling for more efficient and effective government. 
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Figure 1 : UFMS Unified Vision 


The UPMS program is comprised of several large systems development efforts including the NIH 
Business system (NBS), the Health Integrated General Ledger Accounting System (HIGLAS) for 
Medicare Contractors, and the UFMS Global System for the rest of HHS. GAO’s report was focused on 
the UFMS global effort and, therefore, I will direct my remarks to that aspect of the UFMS (see 
Appendix 1: HHS Response to GAO Recommendations for Action). 


To appreciate the size of the systems development effort we have undertaken, one needs to appreciate 
the size and complexity of HHS. In terms of budget and programs, we have become the largest 
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department in the Federal Government, with almost a quarter of total federal outlays. In fiscal year 
2003, HHS was responsible for S505 billion in net outlays. We administer more grant dollars than all 
other federal agencies combined. Our Medicare program processes more than 1 billion claims per year. 
Our Food and Drug Administration alone regulates products that represent 25 cents of every dollar in 
U.S. consumer spending. HHS total employment nationwide is 66-thousand employees. The total 
budget for the UFMS global is $209 million and the current estimated Return on Investment (ROI) is 
15%. 

We have one of the most complex accounting environments in the Federal government. HHS has multi- 
year as well as annual appropriations, entitlement as well as discretionary programs, loan programs, etc. 
This environment presents a major challenge in designing and developing a unified system. 

Among the reasons UFMS is a more complex program than Us name may imply are the following: 

• HHS has a variety of organizational cultures in its operating components 

• UFMS represents a change in the Department’s traditionally decentralized financial management 
model 

• Some operating components were implementing and/or pursuing new financial systems 
independently at the time of the Secretary’s June 2001 memo 

UFMS is one of HHS’ most significant e-business initiatives. In addition to these challenges, the system 

implementation itself is daunting. Five “legacy” accounting systems are in use across HHS. They 

employ different technologies and disparate data definitions and are not electronically integrated. 

Implementing one financial system that can support the diverse, complex needs of each operating 

component requires significant collaboration across the Department. HHS is responding by building a 

knowledgeable team with representation from every operating component to address these challenges 

head on. 
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Benefits ofUFMS 

UFMS is designed to deliver the following benefits: 

• Lower administrative costs, freeing up resources for HHS programs 

• A more secure systems environment 

• Capability for more timely and accurate inform^ion for management decision-making purposes 

• Standardization and streamlining of processes and procedures across HHS 

• Elimination of redundant systems and datab^s 

• Capability for updating financial information in a timely manner 

• Improved ad hoc reporting capability 

• Allow HHS to meet the PMA standards including bringing the Department into compliance with 
the Federal Financial Management Improvement Act and eliminate materia! weaknesses 


Our achievements in developing the UFMS to date include the facts that; 

• AH the agencies are going down the same path, supporting a UFMS vision. 

• Successful conference room pilots (CRPs) were held at CDC, FDA, and the PSC; these helped 
demonstrate some of the system’s functionality. 

• There is agreement on consistent accounting treatment according to USSGL. 

• We’ve streamlined the business processes and anticipate reducing the number of reports. 


Strategic for Achieving Success 


Throughout the implementation process, we have stressed the need for management involvement, and 
the UFMS governance structure ensures that involvement. We have deputies from all HHS operating 
components participating in the Steering Committee. Operating component Chief Information Officers 
(CIOs) and Chief Financial Officers (CFO.s) sit on the Planning and Development Committee. 
Operating component staff are involved in the business analysis, technical analysis and business 
transformation teams. 


As stated above, the implementation of a unified financial system will foster a significant organizational 
transfonnation for HHS, a department that has traditionally followed a decentralized approach to 
financial management. Although this initiative relies on technology, it is at the core, a business 
transformation initiative. From the outset, HHS acknowledged the significance of business 
transformation activities as a critical success element for the program. 

4 



28 


There are several strategies v^'e employed that were specifically derived from best practices and lessons 
learned, always focusing on the outcomes desired: 

■ Executive commitment 

■ Focus on cultural transformation for complex organization 

■ Investing in change management from the beginning 

■ Individuals who know the business are involved to ensure the business requirements will be met 

■ Widespread participation and support across all HHS operating components 

■ Limit scope to core financials 

■ Use phased implementation strategy to reduce risk 

■ Reuse assets of other agencies 

■ Use detailees from HHS operating components to insure built-in agents of change and 
knowledge transfer, and thereby avoid building another federal bureaucracy 

■ An innovative multidimensional and blended training strategy 


The Challenge 

From the outset, the UFMS team understood that the implementation of a unified financial management 
system across HHS posed technical as well as significant organizational and operational challenges. 
History tells us that most large system implementation projects fail. Sources report that these failure 
rates fall between 50-80%. The challenge— how could we ensure success, especially considering the 
complexity of bringing together twelve separate operating components and five accounting systems? 


Strategy for Implementing the Unified Financial Management System 

I would now like to focus my comments on the important topic of the UFMS implementation approach 
that HHS chose at the inception of the program. The GAO report offers a critique of the UFMS 
implementation as at risk due to the lack of a disciplined approach. However, HHS’ approach is not only 
disciplined and appropriate for implementing commercial software, it has in fact kept the UFMS 
program in reach of success- The UFMS implementation plan does contain significant risk, but is 
supported by a risk mitigation process, which is carefully managed dmly., I would like to share with this 
subcommittee how HHS has, from its inception, viewed the UFMS system development philosophy. 
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To this end, please allow me to explain how the four key facets of the UFMS implementation approach 
have set the program on a path to success. 

Management Vision and Governance 

As mentioned earlier, the UFMS program began with a vision by Secretary Thompson in 2001. We have 
kept aim on that vision ever since. In the first eight months of thi.s program HHS managers, together 
with a system integrator and Independent Verification and Validation (IV&V) partners, focused on 
completing a clear, compelling business case and a detailed UFMS implementation plan. Several 
management directives and implementation processes were put in place as a result of this work that we 
have followed with great discipline. One of the key management decisions that we made during the 
planning phase of UFMS was to manage this program as a business transformation initiative and not just 
a system development program. This meant that we had to ensure that the transformation would occur 
in a manner that produced benefits along the way. First, we had to construct approaches and 
management frameworks to ensure that business requirements for financial and accounting operations 
were met by the system. We chose to meet this challenge by adapting HHS financial business processes 
to commonly accepted practices in financial management that are already designed into the Oracle 
software application. As discussed in a recent Government Computer News (GCN) article, “Agencies 
Get Out of the Box”, federal agencies are on an upward trend in using commercial software to change 
financial business practices, In 200.1, ten of thirteen federal agencies used commercial software as the 
foundation for their core financial system implementations.' The UFMS program is a significant part of 
this trend. As we move down this path we are doing some important things: 
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■ We are following industry accepted implementation methods that focus on requirements 
management, quality assurance, risk management and configuration management to configure 
the software for the business needs of HHS.‘ 

■ We collaborate with and leverage the collective lessons as well as assets of other federal 
agencies who are implementing or have already deployed the Oracle Federal Financial software. 

■ We have expended a great amount of energy and focus on communicating our UFMS business 
objectives and training the workfcwx:e on how to use the system. This will drive a steeper ROI 
curve by ensuring that our employees are ready to operate our new financial business model well 
in advance of the UFMS deployment. 

The last point is important because, from inception. HHS has believed that building new competencies 
and acceptance for the UFMS is the path to achieving the Return on Investment (ROI) documented in 
the original UFMS business case. 

As described earlier, to ensure that this business-centric approach is executed effectively, we designed a 
multi-faceted governance structure for UFMS that drives program decisions from key business and 
technology managers from all of the HHS operating components. Figure 2 below depicts the structure 
and components of the UFMS governance structure. 


’ GCN, August 30, 2004, Vol. 23, No. 25 “Agencies Get Out of the Bos”, by jason Milter 
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Figure 2: UFMS Governance 

For the past two years this governance organization has provided great benefits to this program such as: 


• Serving as an best practice governance model and forum for collaborative management between 
UFMS and other HHS enterprise initiatives such as eTravel and eGrants 

■ Executive leadership from HHS operating components that communicates the UFMS strategic 
goals and the importance of participating in the program to their operating components and build 
support throughout HHS and to external stakeholders. 

■ Clearly defined lines of demarcation between UFMS strategic direction setting activities and 
daily program management. The UFMS Steering Committee keeps the program aimed at 
strategic goals and stays abreast of federal management agendas and their impacts on the 
program. The UFMS Planning and Development Committee, compri.sed of the CIOs and CFOs 
of all HHS operating components, oversees performance of the program at a more tactical level 
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and makes recommendations to the UFMS Steering Committee on matters related to the strategic 
direction and pace of this program. 

I am confident that the UFMS governance organization and management processes are among the most 
effective for this type of program anywhere in the federal government. 

UFMS Concept of Operations and Requirements Management 

I would like to cover a few thoughts on the UFMS concept of operations and how this relates to the 
requirements development and tracking that we are managing during the implementation. GAO’s report 
points out that a good Concept of Operations document “should contain a high-level description of the 
operations that must be performed, who must perform them, and where and how the operations will be 
carried out.” This approach defines only one means of successfully deploying a system - building a 
complete Concept of Operations at the start of the program. It also presupposes that a natural 
constituency for the system already exists. HHS is composed of a broad group of operating components 
with diverse missions that share the common objective of securing the public health and welfare of the 
American people. With this long history of autonomy, building a case for UFMS as a “Unified” system 
has been a huge undertaking. 

We started with the components of the Concept of Operations that we could define. Over the course of 
the first year of the program, HHS held numerous workshops focused on the “Case for Change,” “High 
Level Business Processes,” and finally “UFMS System Requirements Specification.” These efforts laid 
the groundwork for what would follow and continued the process of building the necessary 
organizational support for the program. In short, HHS leaders unified employees before we began 
unifying a system. Figure 3 below depicts some of the thinking we completed along this vein. 
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Figure 3: Evolution of HHS Financial Management Operations 


As UFMS moved through the COTS implementation life cycle, we attained additional buy-in through 
the use of Conference Room Pilots, commonly referred to as CRPs, training classes, workshops and 
other events aimed at building competence and adoption around the new system. The CRPs, in 
particular, brought a broad base of managers and users together for live demonstrations of the evolving 
UFMS system. I participated in several of these CRPs and am proud to report that they met their 
objective. We now have broad support across HHS for the new financial system. 

With a supportive and educated user community in place, HHS was finally able to complete the last 
stage of the overall concept for UFMS. We embarked on a shared services study to determine the 
“who” and “where” of the UFMS Concept of Operations. In late 2003 we contracted to perform the 
study and deliver several options to the department. These options were vetted with the operating 
components and a final course of action selected. This was documented in the “Financial Shared 
Services Study Concept of Operations” in April 2004. 
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In COTS systems, requirements statements need to be more flexible and less specific since COTvS 
products are designed to meet the needs of a marketplace instead of satisfying the needs of a particular 
organization. The UFMS implementation is focused on refitting existing HHS business practices to use 
the software as the vendor designed it and configuring the software to meet the needs of the HHS 
business. Let me cite a couple of examples of how our business practices will change as a result of 
implementing the software’s inherent capabilities. 

The HHS Common Vendor File - Today, each HHS component agency maintains separate vendor 
files. UFMS requires a single common vendor file. The single vendor file supports the transition to the 
Common Contractor Registry (CCR) for all HHS Agencies and will enable our managers to perform 
vendor performance and other procurement analyses across agencies. This capability will also give 
HHS the foundation for analyzing past and current contracts with our vendors. With the common vendor 
file, HHS can more effectively manage and negotiate better contractual arrangements with our vendor 
partners. 

Shared Accounting Data - Currently, HHS maintains accounting data within separate databases at each 
Agency, with little commonality in structure or format. UFMS is being implemented to take advantage 
Oracle’s ability to share data values such as for HHS-wide accounting segments that support financial 
processing and repotting. This will promote efficiency in maintaining common data elements, and 
enable more effective department-wide reporting and analysis on HHS programs. 

Note that in each of these examples we are embedding better capabilities that prepare us to fulfill our 
vision of unifying our operations and implementing a more robust accounting shared services business 
model. We built the Concept of Operations one step at a time along a deliberate path to achieve the 
necessary support from all HHS operating components. It was the right path. 
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Figure 4: HHS Enterprise Architecture Framework 


Sound Implementation Strategies 

The UFMS program is driven by several guiding implementation strategies aimed at reducing risk and 
ensuring the program’s success. First, we decided that HHS must base its financial system 
implementation on standards. With UFMS we are implementing standards for the selected technology 
platform, data management and business processes. We chose a commercial software package, Oracle 
Federal Financials, as the technology standard. This decision supports the goal to streamline financial 
operations and processes and reduces business and financial system complexity. With this new 
technology platform HHS can now design and enforce financial data standards for transaction 
processing, data exchange and reporting. For example, we have developed a budget and accounting 
classification structure (BAGS) that is JFMIP-complianl and gives us common data elements, naming 
conventions, organization of genera! ledger data and other attributes that all of the HHS operating 
components use for accounting. We have been and are designing common interfaces with the HHS 
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administrative systems that feed the UFMS. This gives us additional control over how financial data is 
exchanged and significantly reduces the amount of work across HHS that is required to maintain data 
exchange mechanisms. Finally, and most importantly, collaborative efforts across HHS to redesign and 
streamline processes and internal controls have resulted in a unified business model that links operating 
components through process standardization. As you’ll see later in this testimony, we have spent much 
implementation effort focusing on building the competence and confidence of employees in the UFMS 
capabilities to ensure that HHS requirements are met and the Secretary’s vision is achieved. 

A second implementation strategy is aimed at limiting the scope of business and system transformation 
efforts to the core financials capabilities as defined by the Joint Financial Management Improvement 
Program (JFMIP)^. Table 1 describes the mandatory JFMIP core financial management functions 
within the scope of the UFMS Program. 

Continuing to adhere to this principle enables us to exert better control over the UFMS implementation 
limeline, investment, and other related risks. 


- “Cote Finarsciai System Recjuiremencs” (JFMIP-Sr-OZ-Ol, November 2(K)I) jFMIP uses these requirements to certify vendors’ 
co re packages as meeting the core financial funciionaJity required by Fedeul •»i;oncfes. 
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[Table 1. JFMiP Mandatory Core Financial Management Functions 


Function 

Description 

Core Financial 

System 

Management 

Processes necessary to maintain system-processing rules consistent with established financial management 
policy. Sets the framework in which all other «)re financial system functions operate. This function includes 
the: 

■ Accounting classification management process 

■ Transaction control process 

General 

Ledger 

The centra! function of the core financial system fwwides summary information and maintains account 
balances by fund structure and individual accounts. This function includes the: 

■ General ledger account definition process 

■ Accruals, closing and consolidation process 

■ General ledger analysis and reconciliation process 

Funds 

Management 

Primary tool for ensuring that HHS does not obligate or disburse funds in excess of those appropriated 
and/or authorized by the Congress. This function includes the: 

■ Funds allocation process 

■ Budget execution process 

■ Funds control process 

Payment 

Management 

Provides appropriate control over all payments made by or on behalf of HHS. This function includes the: 

■ Payee information maintenance process 

■ Payment warehousing process 

■ Payment execution process 

■ Payment confirmation and follow-up process 

Receivables 

Management 

Supports activities associated with recording cash receipts, including servicing and collecting receivables. 

This function includes the; 

■ Customer information maintenance process 

■ Receivable establishment process 

■ Debt management process 

■ Collection process 

Cost 

Management 

Measures the full Federal Government cost of Goverrrment programs, their activities, and related outputs; 
essential for providing accurate program measurement information, performance measures, and financial 
statements with adequate disclosure of cost activities. This function includes the; 

■ Cost setup and accumulation process 

■ Cost recognition process 

■ Cost distribution process 

■ Working capital and revolving fund process 

Financial 

Reporting 

Provides financial information in a timely manner to support management’s fiduciary role, budget execution, 
fiscal management of program delivery and program decision making, internal and externa! reporting 
requirements, and monitoring of the financial management system. 
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The development and implementation of UFMS, like other complex technology projects is inherently 
risky. HHS has chosen an implementation strategy that is well governed and aggressive. We have also 
prudently placed the UFMS under the scrutiny of an independent verification and validation (IV&V) 
agent who has the duty of monitoring, assessing and reporting on the rigor and execution of our 
management processes to senior leadership of the Department, including myself, in the UFMS 
governance structure. Indeed, the findings in the GAO report were issues that were previously identified 
as a result of this governance and IV&V oversight. Our approach to using an IV&V was validated by 
GAO’S use of UFMS IV&V contractor’s analysis in the GAO report. 

Finally, UFMS is being deployed using an incremental, phased deployment strategy. The first success 
came with the deployment of a new Oracle financial system at the NIH in October of 2003, We will 
next deploy releases of the software at the Centers for Disease Control and Prevention (CDC) and the 
Food and Drug Administration (FDA). As we develop the system we are using implementation 
processes and disciplines that are most appropriate for the configuration and deployment of commercial 
off the shelf software (COTS) applications. GAO cited in their report that UFMS was lacking in the 
manner in which we execute key disciplines such as requirements management, program management 
oversight and risk management. Because of these disciplines 1 am happy to report that, despite recent 
changes to the deployment schedule at one of our sites, the UFMS is a healthy program that is driven by 
an implementation team and workforce who are excited about the future of HHS financial management 
processes as they are implemented as a result of UFMS. We are proud of the fact that after almost 23 
months of implementation progress HHS has met all UFMS major schedule milestones while 
simultaneously preparing the HHS workforce for the eventual release of the system into our business 
operations. We have also effectively navigated through control points that are designed to allow or 
disallow further progress until HHS management feels it prudent to proceed. A recent test readiness 
review (TRR) control point resulted in a modification of the software deployment strategy at one site to 


15 



39 


aiiow additional time for system testing and defect resolution. We are confident that this type of 
discipline will continue to keep this program on a path to success, guided by informed and active HHS 
leadership and collaborations with industry partners. 

A Focus on Business Transformation 

Earlier in my testimony I mentioned that one of the UFMS implementation strategies is focused on 
ensuring that we manage UFMS as a business transformation initiative and not just a system 
implementation effort. This strategy has proven to be a correct one for UFMS and I would like to share 
a few thoughts on what we have accomplished at HHS so far and how we will ensure that the 
transformation continues to take place as the system is deployed. 

At HHS we are confident that UFMS’ past and future achievements in business transformation 
differentiate UFMS from other similar initiatives. A framework consisting of preparing leaders, 
communications, workforce transition and training drives transformation and change for the UFMS 
program. During the planning phase in 2002 the UFMS leadership designed into the governance and 
management structures a team of professionals who execute a full life cycle business transformation 
approach and framework that realizes the Secretary’s vision and drives the needed changes across HHS 
to achieve that vision. 

We are focused on the realities of what we must do to drive adoption of UFMS at HHS. At HHS we 
have many stakeholders who are actively engaged in pursuit of UFMS objectives. This includes 
everyone from the Secretary himself, executive leaders, union organizations and HHS employees. As 
the chart below shows, we art overcoming this one touch at a time with employees at HHS. It depicts 
the numbers of employee “touches” that we have achieved in our formal training sessions, system 
demonstrations, and workshops. We are succeeding in driving competency and adoption for UFMS. 
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Through an accumulation of many focused business transformation events like these we are impacting 
change and adoption of better ways to manage financial operations. 


Driving Adoption and Competency 



Time 


Figure 5; Driving Adoption and Competency 

We have a creative and comprehensive communications program consisting of a website, newsletters, 
posters, emails and videos that communicate progress, benefits and other important facts about the 
UFMS program. For example, one of the most successful communications events to date was a ''Case 
for Change" workshop conducted with senior HHS managers in September 2002 at the beginning of 
implementation activities. This workshop was aimed at early identification of UFMS critical success 
factors, benefits and barriers to success. As a result of this workshop leaders engaged with each other on 
these topics and actively participated in creating initial mitigation strategies for the issues identified. 

The knowledge momentum gained from this workshop is still evident today among HHS leaders. 
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The UFMS training strategy is founded on adult learning theory, leading practices and lessons learned 
from multiple similar implementations in the Federal Government. It presents a blended learning 
solution that is anchored in a irain-the-trainer approach. It also presents a series of highly integrated 
planning activities and workshops designed to build a robust learning infrastructure, including a wide 
network of UFMS super and master users. Curriculum development and learning activities are 
supported by a sophisticated training development platform, OnDemand. We planned training this way 
to account for the fact that the hundreds of people who will use UFMS not only have great diversity in 
their learning styles and preferences, but they are also geographically dispersed. We already see the 
positive effects of these efforts. Three years ago most HHS employees impacted by this business 
transformation had little confidence in the system. Today, many employees have already learned how to 
use the various modules that comprise the system. 


UFMS Achievements and Successes So Far 

UFMS is scheduled for completion in FY 2007. As mentioned earlier we at HHS are very proud of the 
accomplishments we have achieved in partnership with the systems integrator and IV&V agent. I would 
like to spend a few minutes sharing with the committee a chronology of some major milestones we have 
accomplished to date on the path to significantly streamlining and transforming financial operations and 
systems at HHS. 

■ November 2001. Awarded the UMS systems integration contract to KPMG Con.suiting Inc. (now 
BearingPoint Inc.) 

• September 2002. Completed detailed planning for the UFMS implementation. Di this plan we laid a 
strategic roadmap for the implementation, documented approaches and strategies for executing a 
successful program, laid initial staffing plans, and described overall governance, risk management 
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and performance measurement frameworks. We submitted this comprehensive plan to 0MB where 
it was well received. 

November 2002. Submitted the UFMS business case document to OMB. This document described 
implementation approach alternatives and respective cost-benefit analyses were considered in UFMS 
planning. 

November 2002. Formally kicked off CDC implementation. 

August 2003. Giobal/CDC CRPl conducted at the CDC with teleconferencing to our PMO 
office in Rockville, Maryland. CRP is a prototyping technique used to help determine and validate 
UFMS design and configuration. It takes the form of an interactive, scripted working session in 
which subject matter experts provide feedback on proposed configurations, business requirements, 
and organizational impacts and anticipated training requirements. 

October 2003. Successfully deployed Oracle Federal Financials at the NIH. The NIH served as the 
initial UFMS “proof of concept.” Its overwhelming success signaled the green light for 
implementations at other Agencies. The NIH Oracle General Ledger, Federal Administration and 
Projects Accounting financial modules were deployed in September 2003, along with an Enterprise 
Single Sign-On capability and Single Point of Entry Portal. Gelco Travel Manager was also 
deployed in September 2003 with Oracle Accounts Payable, Purchasing, Accounts Receivable and 
Cash Management as sub-ledger financial support modules. (Note: NIH will migrate to the eTravel 
solution by end of FY 2006). 

October 2003. Formally kicked off the FDA UFMS implementation. 

February 2004. Approximately 100 staff representing all Regional Offices and Centers attended the 
FDA’s CRPl . The FDA Commissioner, the CFO and the Deputy CFO made a special appearance. 
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■ March/April 2004. GiobayCDC CRP 2. 

■ April 2004. Formaily kicked off the PSC/Customer Operating Divisions implementation. The 
event drew 100 participants and included speeches by me and other key leaders from across HHS. 
Presentation topics included program team structure and governance, major milestones and the 
importance of involving subject matter experts from the impacted communities in all facets of the 
implementation. 

■ August 2004: PSC CRP 1 was conducted over a two week period in Washington, DC. Over 180 
participants from the PSC and its customer operating components attended. 

■ October 2004: Deployment of General Ledger and Payroll at CDC and FDA. 

■ First Quarter Fiscal Year 2005; Deployment of Grants processing capability at CDC 


Deployment Strategy Update 

The risk inherent in the HHS approach comes from an aggressive implementation plan, designed to 
begin securing value for the taxpayer and the HHS community at the earliest possible time. October 
2004 was chosen as the aggressive goal for the pilot implementation in order to expedite discovery of 
system defects and increase chances that the system would go live in FY 2005. This strategy ensures 
adequate time to deploy a quality system in the event unsuspected technical issues and risks were 
uncovered. All things being equal, if a system functional capability becomes high risk for the pilot 
implementation, it can be deferred to a subsequent release without impacting the overall 
implementation. 

One of the most challenging aspects of any COTS implementation is the continual management of the 
inter-related but sometimes competing priorities of cost, schedule, requirements, and resources. Early in 
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the program, the UFMS leadership team made the decision that incremental benefits from UFMS would 
be obtained through a phased deployment of the system. A well-defined set of phases was established. 
A core set of functional requirements will be available in the October 2004 release for Centers for 
Disease Control and Prevention (CDC) and Food and Drug Administration (FDA). Additional 
capabilities will be added in subsequent releases resulting in a complete. Department wide core 
accounting system in 2007. This is an industry best practice risk reduction technique, and also allows 
the UFMS program to give priority to meeting the October 2004 “go live” schedule for CDC and FDA. 
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Figure 6; UFMS Milestones and Current Timeline 


The flexibility afforded by the phased implementation ^proach, combined with the Capability Maturity 
Model (CMM) Level 3 compliant development processes, provide the balance necessary to manage the 
risks associated with an aggressive but achievable program schedule. One key risk in this approach, as 
GAO identified, is that the formal testing phase comes late in the overall timeline. This leaves limited 
time to resolve and retest unexpected issues as they are uncovered. 


21 



45 


Testing Strategy 

Testing of COTS software, like UFMS, takes on a significantly different focus from the testing of 
custom developed systems. A key reason for choosing a COTS software package is to leverage the 
investment made by the COTS vendor in producing a mature product that has been thoroughly tested. 
Very mature products, such as Oracle U.S. Federal Financials, require little or no low-level testing. It is 
sufficient to conduct functional testing to validate the application’s ability to support HHS specific 
business processes. Consequently, the focus of the test efforts is system-level, and focused on code 
developed for HHS specific extensions and interfaces. The other important difference in COTS 
implementations is the inclusion of the Finance, Business, and Program stakeholders in the testing 
process. Industry experience has repeatedly shown that including key stakeholders in testing plays an 
important role in setting expectations and introducing future users to the system in a gradual way. The 
UFMS test effort is a multi-phased approach prefaced by Conference Room Pilot (CRP) activities, 
continuing with formal test activity, including unit, integration, ^d system testing, and culminating in a 
User Acceptance Test (UAT). 

The GAO report takes issue with the timing of the testing in the program plan and HHS agrees that 
system testing ideally occurs earlier in the schedule. However, even though the testing occurs relatively 
late in the timeline, it is subject to extreme scrutiny and management oversight, with regular review 
meetings, daily summaries and detailed communication. All lest scripts and results are rigorously 
tracked in “TestDirector,” and testing teams manage defects on a daily basis. HHS believes that the 
majority of system defects will be identified as a result of this level of scrutiny, continuing heavy 
involvement in testing by Financial, Business and Program leaders, and the fact that UFMS is a very 
mature COTS product. 
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Each testing phase (CRPs, Unit-level testing. Integration Testing, System Testing, UAT) has a detailed 
plan developed that defines what will be tested, how it will be tested, where it will be tested, and who 
will test it. The results of each phase are recorded, defects noted, corrective actions taken, and 
functionality retested in each phase as necessary. A series of Go/No-Go checkpoints are built into these 
testing phases. These checkpoints had not yet been triggered at the time of the GAO review. 

The UFMS implementation schedule for the CDC deployment was aggressive with significant risk in 
regard to meeting the October schedule. This led HHS to tailor its testing plans so that testing phases that 
normally occur sequentially have been allowed to overlap, but steps have never been skipped or 
eliminated. As testing has unfolded, HHS has taken the recommendations of the IV &V contractor and 
PMO and is analyzing system integration test result.s prior to deploying the first release of the system at 
the CDC and FDA. HHS does acknowledge GAO’s comments that the testing of this system is occurring 
relatively late in relation to the October objective for deployment of the Global Pilot. At the time we 
prepared the response to the GAO report, HHS was analyzing system integration test results. This 
assessment resulted in a recommendation to the UFMS Steering Committee to modify the current software 
release strategy. 

Software Release Strategy 

UFMS has employed an ongoing software release strategy designed to ensure maximum capability 
while ensuring we meet scheduled milestones. Upon the completion of the “Gap Closure Analysis” in 
the summer of 2003, the UFMS Change Control Board reviewed the recommended actions to close 
requirements gaps. Many resolutions and extensions could be employed within the target go-live 
without impacting schedule. However some requirement gap actions would not be implemented within 
the time line. We understood that some functionality would be in a future release. In February 2004 at 
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the time of the schedule review, we understood the need for perfect execution of remaining tasks to meet 
the target of October go-live. We decided to press on with that understanding. In May, based on 
another schedule review, we realized the need not only for perfect execution, but also that meeting the 
October go-live target would require heroic efforts on the part of HHS staff and contractors. We also 
were aware that the ability to .schedule certain system components for phased deployment would 
preserve all work done to date. We wished to retain a sense of urgency, and deliberately pressed on. In 
September 2004, we realized the need to revise the UFMS deployment strategy to maximize the 
investment in UFMS. This decision came due to results from test readiness review (TRR) and advice by 
IV&V. 

Following a detailed system readiness review, and in keeping with industry accepted program 
management practices for COTS system implementations, the UFMS leadership team decided to follow 
a phased approach to the pilot UFMS deployment at the CDC. This results in a release strategy for the 
CDC, which allows adequate time to address technical issues identified during testing and readiness 
review and to deploy a quality system in FY 2005. The overall deployment plan for UFMS is on 
schedule for completion in FY 2007. 

Through September, detailed updates to the UFMS deployment strategy have been developed to manage 
the tightly integrated deployments at the CDC and the FDA, Integration and system testing, certain 
conversion activities, the development of a grants module and CAN realignment, select infrastructure 
tasks, and the staff assigned to those activities, will continue through October 2004. User acceptance 
testing, training, specific conversion activities, and infrastructure tasks will require updated deployment 
schedules for the period October 2004 through April 2005. 

October 2004 will see a significant achievement for UFMS. The Centers for Disease Control and 
Prevention (CDC) and the Food and Drug Administration (FDA) will deploy the General Ledger and the 
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Accounting for Pay System (AFPS) for payroll activities. For the FDA, this represents over 60% of its 
dollars. With the inclusion of grants processing in the first quarter of FY 2005, CDC will process over 
50% of its dollars and transactions. CDC and FDA will deploy the comprehensive OracleAJFMS suite 
in April 2005. This follows the successful deployment of the NIH phase of UFMS in October 2003. 


Conclusion 

I hope that the information I have provided here today demonstrates how HHS has undertaken the 
UFMS project. We have utilized a number of industry best pr^tices and have been schedule-driven. 
The benefits of this approach are that over the past three years we have been able to contain costs, 
contain scope and have made our workforce proceed on a daily basis with a sense of urgency. We 
understand the risks of this approach and have worked hard to mitigate and manage those risks. Unlike 
other systems development efforts that concentrate mainly on software and requirements, we have 
invested more of our energy in the people and institutions with the result that our people are being 
readied for the new system at a faster pace than would otherwise be possible. I believe our disciplined 
approach to the development of the UFMS will help ensure our ultimate success and that this 
information will be of value to this committee in their oversight efforts. At this time. I will be happy to 
answer any questions. 
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Appendix 1: HHS Response to GAO Recommendations for Action 


1. Determine the system capabilities that are ne<»ssary for the CDC deployment. 

HHS has determined the system capabilities necessary for the CDC deployment over the last two 
years. Following details our approach. 

• HHS has developed the UFMS Core Financial Target Business Mode) description of business 
operations and design of how the operations will be performed at HHS across multiple, coordinated 
entities. 

• For HHS, the target business model for financial management describes how financial management 
will be performed including at the CDC. 

• UFMS has established a central information repository (Rational's RequisitePro), which includes 
over 2100 requirements and their attributes (e.g. requirement type, origin, applicable Operating 
Divisions (e.g. CDC, FDA), status and other management information) pertinent to the UFMS 
environment. 

• UFMS requirements are also documented in the UFMS Baseline Requirements document that was 
reviewed and approved by the PDC and Steering Committee. 

• Requirements not satisfied by the basic COTS package (Oracle U.S. Federal Financials), were 
assessed to determine an appropriate business solution. These “Gap" requirements identifying either 
a business process change or an Interface, Extension, Repon or Conversion program were prioritized 
based on the UFMS release schedule; therefore CDC ra|uired capabilities were developed first. 

2. Identify the relevant requirements related to the d^ired system capabilities for the CDC 
deployment. 

• UFMS has established a central information repository (Rational’s RequisitePro), which includes 
over 2100 requirements and their attributes (e.g requirement type, origin, applicable Operating 
Divisions (e.g. CDC, FDA), status and other management information) pertinent to the UFMS 
environment. 

• UFMS requirements are also documented in the UFMS Baseline Requirements document that was 
reviewed and approved by the PDC and Steering Committee. 

• Requirements not satisfied by the basic COTS package (Oracle U.S. Federal Financials), were 
assessed to dciermine an appropriate business solution. These “Gap” requirements identifying either 
a business process change or an Interface. Extension. Repon or Conversion program were prioritized 
based on the UFMS release schedule; therefore CDC required capabilities were developed first. 

• For each Interface, Extension, Report and Conversion program identified as required for the CDC 
deployment a Functional Design Specification and a Technical Design Specification was developed. 
These design documents containing specific business rules (design constraints) that state 
unambiguously the functional UFMS must provide. 

• Each design constraint was captured in the central requirement repository and lied to the parent 
requirement that established the need for that particular interface, extension, report or conversion 
program at the CDC 

• A release specific Requirements Tracability Verification Matrix (RTVM) has been built to verify that 
all requirements are met by the system deliverable and to demonstrate to HHS and outside parties that 
we have sati.sfied the system requirements allocated to the release (e.g. the CDC deployment). 

3. Clarify, where necessary, any requirements to ensure they (1) fully describe the capability to be 
delivered, (2) include the source of the requirement, and (3) are unambiguously stated to allow for 
quantitative evaluation. 

• UFMS has established a central information repository, which includes over 2100 requirements and 
their attributes (e.g. requirement type, origin, applicable Operating Divisions (e.g. CDC, FDA. NIH), 
status and other management information) pertinent to the UFMS environment. 
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• UFMS requirements are also documented in the UFMS Baseline Requirements document that was 
reviewed and approved by the PDC and Steering Committee. 

• Requirements not satisfied by the basic COTS package (Oracle U.S. Federal Financials), were 
assessed to determine an appropriate business solution. These “Gap” requirements identifying either 
a business process change or an Interface, Extension, Report or Conversion program were prioritized 
based on the UFMS release schedule; therefore CDC required capabilities were developed first. 

• For each Interface, Extension, Report and Conversion program identified as required for the CDC 
deployment a Functional Design Specification and a Technical Design Specification was developed. 
These design documents containing specific business titles (design constraints) that state 
unambiguously the functional UFMS most provide. 

• Each design constraint was captured in the central requirement repository and tied to the parent 
requirement that established the need for that particular interface, extension, report or conversion 
program at the CDC. 

• Capabilities expressed in requirements that was assessed and demonstrated as being met by the basic 
COTS package have not been restated in additional detail. These “Fits” were verified through a series 
of Conference Room Pilots (CRPs). 

• For each Interface, Extension, Report and Conversion program identified as required for the CDC 
deployment a Functional Design Specification and a Technical Design Specification was developed. 
These design documents containing specific business rules (design constraints) that state 
unambiguously the functional UFMS must provide. 

• Each design constraint is captured in the central requirement repository and tied to the parent 
requirement that established the need for that particular interface, extension, report or conversion 
program. 

• The RTVM is used to track all UFMS requirements and design constraints and verify they are all 
tested during testing. 

4. Maintain traceability of the CDC-reiated requirements from their origin through Implementation. 

• HHS has from the beginning maintained a detailed history of the UFMS requirements that includes 
mapping each requirement to the specific Integrated Bu-siness Processes where that capability is used, 
the lest scripts that are executed to verify compliance and the results of each test script. 

• A release specific Requirements Tracabilily Verification Matrix (RTVM) has been built to verify that 
all requirements are met by the system deliverable and to demonstrate to HHS and outside parties that 
we have satisfied the system requirements allocated to the release (e.g. the CDC deployment). 

• Through the RTVM, requirements management and testing are inseparably linked. In addition; 

o The RTVM is used to track all UFMS requirements and design constraints and verify they are 
all tested. 

o The UFMS Final Baseline Requirements have been mapped to integrated business processes 
at the script level. 

o For each Interface, Extension. Report and Conversion program a Functional Design 

Specification and a Technical Design Specification is developed. These design documents 
containing specific business rules (design constraints) that state unambiguously the ftinctional 
UFMS must provide. 

o The requirements module in TestDirector maintains the list of testable requirements, 
organized by module, in order to map requirements to Test Scripts. 

5. Use a testing process that employs effective requirements to obtain the quantitative measures 

necessary to understand the assumed risks. 

• Each testing phase (CRPs, Unit-level testing. Integration Testing, System Testing, UAT) has a 
detailed plan developed that defines what will be tested, how it will be tested, where it will be tested, 
and who will test it. The results of each phase are recorded, defects noted, and correclive actions 
taken and functionality retested in each testing phase as necessary. 

• Testing is subject to extreme scrutiny and management oversight, with regular review meetings, daily 
summaries and detailed corruuunication. 
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• All iCvSl scripts and results are rigorously tracked in TestDirecior, and testing teams manage defects on 
a daily basis. 

• The UFMS Final Baseline Requirements have been mapped to integrated business processes at the 
script level. 

• To assess system stability and readiness we are tracking the following quality indicators: 

o Percent of release requirements tested 
o Number of requirement change requests 
o Percent of Integrated Process test scripts completed 
o Percent of test scenarios passed testing 
o Number defects detected 
o Number defects closed 

• HHS instituted a series of Control gates (e.g. our Test Readiness Reviews [TRRs]) with defined go/no 
go criteria. These control gates provide HHS the ability to assess whether the UFMS project is fully 
prepared to begin the next phase. We check to determine that: 

o necessary documentation set is complete and up-to-date, 
o all hardware, software, and support tools are up-to-date and ready for use, 
o project controls, processes, and monitoring mechanisms are in place and fully understood, 
o any unresolved issues are fully addressed, including a discussion of any applicable risk 
mitigation strategies. 

6. Validate that data conversion efforts produce reliable data for use in UFMS. 

• Data conversions represent one of the riskiest areas of an ERP implementation. To mitigate this risk, 
UFMS is utilizing a series Mock conversions to perform dress rehearsals of the data conversion 
process. 

o The first mock conversion was the initial conversion and setup of necessary background data 
(e.g. vendor tables). 

o A series of additional mock conversions (3, 4, 5, and 6) further validated the conversion 
programs and data cleanup efforts. The data from one of these more mature mock 
conversions will be made available for system testing. Following these mock conversions, 
final adjustments are made to the conversion programs and additional data cleanup may 
occur. 

o A final test of the conversion programs is performed in the final month prior to go live and Is 
used as the final data validation and reconciliation prior to User Acceptance Testing. 

• The Accounting Treatment Team is examining each transaction to verify that the appropriate 
accounting codes arc being used. 

• HHS has brought in an independent vendor to review and validate the accounting actions preformed 
by UFMS. 

7. Verify systems interfaces function properly so that data exchanges between systems are adequate to 

satisfy system needs. 

• The focus of the test efforts is system-level, and focused on code developed for HHS specific 
extensions and interfaces. 

• Each testing phase (CRPs, Unit-level testing. Integration Testing, System Testing, UAT) has a 
detailed plan developed that defines what will be tested, how it will be tested, where it will be tested, 
and who will lest it. 

• HHS has mapped each requirement to the specific Integrated Business Processes where that capability 
is used, the test scripts that are executed to verify compliance and the results of each lest script 
recorded. 

• Integrated Business Processes define data flow from “end-to-end”; from the input of data from feeder 
systems to the production of financial statements. These end-to-end processes are used at each level 
of testing; unit, integration and acceptance. 
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• The same code base is being used to build conversion programs and feeder system interfaces. This 
can be done because the same types of data is processed and results in the code being repetitively 
tested under a wider set of conditions than might otherwise be possible. 

• UFMS built a comprehensive RTVM in which the requirements are mapped to Business Processes to 
Test Scripts, resulting in a full trace of requirements to the appropriate testable area of Oracle, and the 
method used to verify that each requirement has been satisfied. The RTVM is maintained in an 
industry standard COTS testing tool - Mercury’s TestDireclor. 

• The RTVM is used to track all UFMS requirements and design constraints and verify they are alJ 
tested. 

• The UFMS Final Baseline Requirements were mapped to integrated business processes at the script 
level. 

• For each interface. Extension, Report and Conversion program a Functional Design Specification and 
a Technical Design Specification is developed. These design documents containing specific business 
rules (design constraints) that stale unambiguously the functional UFMS must provide 

• The requirements module in TesiDirector maintains the list of testable requirements, organized by 
module, in order to map requirements to Test Scripts. 

8, Measure progress based on quantitative data rather than the occurrence of events. 

• Since the inception of the project, HHS has focused on measuring three key program control facets 
instead of instituting outcome measures all along the implementation pathway. These areas are 
Quality . Cost , and Schedule . 

• For two years now HHS has collected and assessed monthly Cost Performance Index data (CPI) and 
Schedule Performance index (SPi) data to determine the degree to which the program is efficiently 
using budget and schedule. 

• Critical path schedule analysis is used as a predictive schedule performance gauge to help our 
managers determine if schedule slippage is occurring. 

o any applicable risk mitigation strategies. 

• Until HHS reached the testing phases of the UFMS implementation, most of the focus on quality 
dealt with UFMS documents and artifacts. We are now conducting a very through and rigorous 
process for quantifying the results of test defect tracking and resolution. To assess system stability 
and readiness we are tracking the following quality Indicators: 

o Percent of release requirements tested 
o Number of requirement change requests 
o Percent of Integrated Process test scripts completed 
o Percent of test scenarios passed testing 
o Number defects delected 
o Number defects closed 

• HHS instituted a series of Control gates (e.g. our Test Readiness Reviews [TRRs]) with defined go/no 
go criteria. These control gates provide HHS the ability to assess whether the UFMS project is fully 
prepared to begin the next phase. We check to determine that: 

o necessary documentation set is complete and up-to-date, 
o all haidware, software, and support tools arc up-to-date and ready for use. 
o project controls, processes, and monitoring mechanisms are in place and fully understood, 
o any unresolved issues are fully addressed, including a discussion of 
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Before proceeding with further implementation of UFMS after CDC, GAO recommends the Assistant 
Secretary for Budget, Technology, and Finance following 14 actions; 


1. Develop and effectively implement a plan on how HHS will implement the disciplined processes 
necessary to reduce the risks associated with this effort to acceptable levels. This plan should 
include the processes, such as those identified by S£1 and IEEE, that will be implemented and the 
resources, such as staffing and funding, needed to implement the necessary processes. 

• HHS has an effective implementation plan that we have been executing since October 2002. 

• In October 2002 the HHS Steering Committee for UFMS approved a detailed Implementation Plan 
that identified the tasks, strategies, plans, and processes that would be required to implement UFMS. 

• In executing the approved UFMS implementation plan, HHS developed and is actively using the 
plans, strategies, processes, and lower level procedures it identified. These Include the resource 
loaded Project Plan, Change Control Management Plan. Requirement Management Plan, Risk 
Assessment and Mitigation Plan, Quality Assurance Procedure, Interface Strategy, Conversion 
Strategy and Testing Approach. 

• Each plan, strategy, and process is tailored for HHS purposes but carefully designed to follow 
industry best practices, including those of Oracle itself. Tailoring is a common, accepted practice that 
is a recommended part of all development methodologies including those used by DoD. 

2. Develop a concept of operations, in accordance with recognized industry standards such as those 
promulgated by IEEE. The concept of operations should apply to all HHS entities that will be 
required to use UFMS. Hiis concept of operations should contain a high-level description of the 
operations that must be performed, who must perform them, and where and how the operations 
will be carried out, and be consistent with the current vision for the HHS information system 
enterprise architecture. 

• In July 2002 HHS developed a targe! business model, which has been a guiding document from its 
creation. This foundation document is the equivalent to the “Concept of Operations’. 

• The Core Financial Target Business Model is a description of business operations and design of how 
the operations will be performed at HHS across multiple, coordinated entities. 

• The target business m^d presents the target environment by each major JFMIP core financial 
functional area and associated major business. It also defines the interaction between OS at the 
Department-level and the component agencies (e.g., defining accounting policy), as well as the 
interaction between Program Support Center (PSC) and the PSC-serviced agencies (e.g., external 
reports submitted to the serviced agencies for review and approval). 

• HHS started with the “what” of the system. Over the course of the first year of the project, HHS held 
numerous workshops focused on the Case for Change, the High Level Business Processes, and finally 
the UFMS System Requirements Specification. These efforts both laid the groundwork for what 
would follow and continued the process of building the necessary organizational support for the 
project 

• Additional buy in was established through the use of Conference Room Pilots. 

• UFMS is at a higher level of Enterprise Architecture attainment than 97% of other agencies, having 
completed all ot stage 2 readiness, along with significant components of stage 3. UFMS is a critical 
and defining pan ot the federal governments overall Enterprise Architecture. 

• Users of UFMS will access the system across HHSnet, the Department’s new enterprise network. 

3. Implement a requirements management process that develops requirements that are consistent 
with the concept of operations and requires that the resulting requirements have the attributes 
associated with good requirements that include for each requirement (1) fully describing the 
functionality to be delivered, (2) including the source of the requirement, and (3) stating the 
requirement in unambiguous terms that allows for quantitative evaluation. 


30 



54 


• HHS has an established UFMS requirements management process that is a detailed, systematic 
approach to identify, document, organize, communicate, and manage changes in the requirements 
applicable to the UFMS Program. 

• UFMS established a centra! information repository, which includes over 2100 requirements and their 
attributes (e.g. requirement type, origin, applicable Operating Divisions, status and other management 
information) pertinent to the UFMS environment. UFMS requirements arc also documented in the 
UFMS Baseline Requirements document that was reviewed and approved by the PDC and Steering 
Committee. 

• HHS has from the beginning maintained a detailed history of the UFMS requirements that includes 
mapping each requirement to the specific Integrated Business Processes where that capability is used, 
the test scripts that are executed to verify compliance and the results of each test script. 

• For each Interface, Extension, Report and Conversion program a Functional Design Specification and 
a Technical Design Specification is developed. These design documents containing specific business 
rules (design constraints) that state unambiguously the functional UFMS must provide. 

• Each design constraint is captured in the central requirement repository and tied to the parent 
requirement that established the need for that particular interface, extension, report or conversion 
program. 

• The RTVM is used to track all UFMS requirements and design constraints and verify they are all 
tested during testing. 

Maintain traceability of requirements among the various implementation phases from origin 

through Implementation. 

• HHS has from the beginning maintained a detailed history of the UFMS requirements that includes 
mapping each requirement to the specific Integrated Business Processes where that capability is used, 
the test scripts that are executed to verify compliance and the results of each test script. 

• UFMS has established a central information repository, which includes over 21 00 requirements and 
their attributes (e.g. requirement type, origin, applicable Operating Divisions, status and other 
management information) pertinent to the UFMS environment in a COTS product designed for this 
purpose: RequisitePro (ReqPro). 

• Requirements and their associated attributes have been developed, adapted, and reused, which results 
in an efficiency that lowers the effort and cost of development at each site, as well as subsequent 
iterations and related projects. 

• For each Interface, Extension, Report and Conversion program a Functional Design Specification and 
a Technical Design Specification is developed. These design documents containing specific business 
rules (design constraints) that state unambiguously the functional UFMS must provide. 

• UFMS has built a comprehensive RTVM in which the requirements are mapped to Business 
Processes to Test Scripts, resulting in a full trace of requirements to the appropriate testable area of 
Oracle, and the method used to verify that each requirement has been satisfied. The RTVM is 
maintained in an industry standard COTS testing tool - Mercury’s TestDirector. 

• The RTVM is used to track all UFMS requirements and design constraints and verify they are all 
tested. 

• The UFMS Final Baseline Requirements have been mapped to integrated business processes at the 
script level, 

• The requirements module in TestDirector maintains the list of testable requirements, organized by 
module, in order to map requirements to Te.st Scripts. 

Confirm that requirements are effectively used for: 

5. determining the functionality that will be available in UFMS at a given location, 

6. implementing the required functionality, 

7. supporting an effective testing process to evaluate whether UFMS is ready for deployment, 

• UFMS established a central information repository, which includes over 2100 requirements and their 
attributes (e.g. requirement type, origin, applicable Operating Divisions, status and other management 
information) pertinent to the UFMS environment. UFMS requirements are also documented in the 
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UFMxS Baseline Requirements document that was reviewed and approved by the PDC and Steering 
Committee. 

• A Requirements Tracability Verification Matrix (RTVM) has been built to verify that all 
requirements are met by the system dcJiverable and to demonstrate to HHS and outside parties that 
we have satisfied the system requirements. ITtrough the RTVM requirements management and 
testing are inseparably linked. In addition: 

o The RTVM is used to track ail UFMS requirements and design constraints and verify they are 
all tested. 

o The UFMS Final Baseline Requirements have been mapped to integrated business processes 
at the script level. 

o For each Interface, Extension, Report and Conversion program a Functional Design 

Specification and a Technical Design Specification is developed, 'fhese design documents 
containing specific busines.s rules (design constraints) that state unambiguously the functional 
UFMS must provide. 

o The requirements module in TestDirector maintains the list of testable requirements, 
organized by module, in order to map requirements to Test Scripts. 

8. validating that data conversion efforts produce reliable data for use in UFMS, and 

• Data conversions represent one of the riskiest areas of an ERP implementation. To nuiigute this risk, 
UFMS is utilizing a series Mock conversions to perform dress rehearsals of the data conversion 
process. 

o The first mock conversion was the initial conversion and setup of necessary background data 
(e.g. vendor tables). 

o Second and third mock conversions further validated the conversion programs and data 
cleanup efforts. The data from mock conversion 3 was made available for system testing in 
August. Following mock conversion 3. final adjustments are made to the conversion 
programs and additional data cleanup may occur. 

o A final lest of the conversion programs (e.g. Mock conversion 4) is performed in the final 
month prior to go live and is used as the final data validation and reconciliation prior to User 
Acceptance Testing. 

• The Accounting Treatment Team is examining each transaction to verify that the appropriate 
accounting codes are being used. 

• HHS has brought in an independent vendor to review and validate the accounting actions preformed 
by UFMS 

9. verifying that systems interfaces function properly so that data exchanges between systems 

are adequate to satisfy each system’s needs. 

• The focus of the test efforts is system-level, and focused on code developed for HHS specific 
extensions and interfaces. 

• The Finance, Business, and Program leaders, have been active in the project and its design from the 
beginning, are heavily involved in testing the end product. 

• Each testing phase (CRPs, Unit-level testing. Integration Testing, System Testing, UAT) has a 
detailed plan developed that defines what will be tested, how it will be tested, where it will be tested, 
and who will test it. 

• UFMS built a comprehensive RTVM in which the requirements are mapped to Business Processes to 
Test Scripts, resulting in a fijll trace of requirements to the appropriate testable area of Oracle, and the 
method used to verify that each requirement has been satisfied. The RTVM is maintained in an 
industry standard COTS testing tool - Mercury’s TestDirector. 

10. Develop and implement a testing process that uses adequate requirements as a basis for testing a 

given system function. 

• Testing of COTS based systems has a significantly different focus from the testing of custom 
developed systems. Among the keys reasons for choosing a COTS based implementation is to 
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leverage the investment made by the COTS vendor in producing a mature product that has been 
thoroughly tested. Very mature products, such as Oracle U.S. Federal Financials, require little or no 
low-level testing. 

• The focus of the test efforts is system-level, and focused on code developed for HHS specific 
extensions and interfaces. 

• The Finance, Business, and Program leadere, have been active in the project and its design from the 
beginning, are heavily involved in testing the end product. 

• Each testing phase (CRPs, Unit-level testing. Integration Testing, System Testing, UAT) has a 
detailed plan developed that defines what will be tested, how it will be tested, where it will be tested, 
and who will test it. 

• UFMS has built a comprehensive RTVM in which the requirements are mapped to Business 
Processes to Test Scripts, resulting in a full trace of requirements to the appropriate testable area of 
Oracle, and the method used to verify that each R^uirement has been satisfied. The RTVM is 
maintained in an industry standard COTS testing tool - Mercury’s TesiDirector. 

• The RTVM is used to track all UFMS requirements and design con,straints and verify they are all 
tested. 

• The UFMS Final Baseline Requirements have been mapped to integrated business processes at the 
script level. 

• For each Interface, Extension, Report and Conversion program a Functional Design Specification and 
a Technical Design Specification is developed. These design documents containing specific business 
rules (design constraints) that state unambiguously the functional UFMS must provide. 

• The requirements module in TestDirector maintains the list of testable requirements, organized by 
module, in order to map requirements to Test Scripts. 

• Formalize risk management procedures to consider: 

11. ail risks currently applicable to the UFMS project are identified, and 

12. that risks are only closed after the risk is no longer applicable rather than once 
management has developed a mitigation strategy. 

• The UFMS project relies on a well-implemented risk management process that u,ses buslnes,s best 
practices developed by leading providers across market segments. 

• The UFMS risk management process is the result of a Cooperative Research and Development 
Agreement (CRADA) between BearingPoint and the Software Engineering Institute (SEI) to co- 
develop a best practice based risk management program. 

• The continuous risk management process that is followed by the UFMS program includes weekly 
meetings with HHS Program Management to review current and past risks, update and refine 
mitigation strategies, and assess i.ssues that might become risks to the success of UFMS. 

• HHS adjusted the risk management processes to keep all risks in an open status until they are either 
realized or an appropriate mitigation has been successful. In addition, the UFMS PMO has decided to 
maintain listings for both open and closed risks to maintain their visibility. It is important to note that 
the closed risks highlighted by GAO Included risks (e.g.. funding) that the UFMS PMO felt could be 
closed for one particular year and re-opened If the risk occurred during subsequent years within the 
life of the project. 

13. Develop and implement a program that will identify the quantitative metrics needed to evaluate 

project performance and risks. 

• For two years now HHS has collected and assessed monthly Cost Performance Index data (CPI) and 
Schedule Performance index (SPI) data to determine the degree to which the program is efficiently 
using budget and schedule. 

• Critical path .schedule analysis is used as a predictive schedule performance gauge to help our 
managers determine if schedule slippage is occurring. 

• To assess system stability and readiness we are tracking the following quality indicators; 

o Percent of release requirements tested 
o Number of requirement change requests 


33 



57 


o Percent of Integrated Process test scripts completed 
o Percent of test scenarios passed testing 
o Number defects detected 
o Number defects closed 

• The continuous risk fuanagemeni process that is followed by the UFMS program includes weekly 
meetings with HHS Program Management to review current and past risks, update and refine 
mitigation strategies, and assess issues that might become risks to the success of UFMS. 

14. Use quantitative measures to assess progress and compliance with disciplined processes. 

• Our focus has been on measuring three key program control facets instead of instituting outcome 
measures all along the implementation pathway. These areas are quality, cost, and schedule. 

• For two years now HHS has collected and assess monthly Cost Performance Index data (CPI) and 
Schedule Performance Index (SPI) data to determine the degree to which the program is efficiently 
using budget and schedule. 

• Critical path schedule analysis is used as a predictive schedule performance gauge to help our 
managers determine if schedule slippage is occurring. 

• To assess system stability and readiness we are tracking the following quality indicators: 

o Percent of release requirements tested 
o Number of requirement change requests 
o Percent of Integrated Pr(K:ess test scripts completed 
o Percent of test scenarios passed testing 
o Number defects detected 
o Number defects closed 
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To help ensure thai HHS reduces risks in the agency wide IT environment the following 7 actions should be 
taken: 


1 . Conduct assessments of operating divisions* information security general controls that have not 
been recently assessed. 

• HSS has progressively increased key system security metrics reported in the FISMA quarterly report. 
Key items for the 3rd quarter of 2004 included; 

o 96% of systems have been assessed for risk, 
o 95% of systems have security plans, 
o 93% of systems have been certified and accredited 

• A Managed vSecurity Service (MSS) using an automated intrusion detection tool to monitor, detect, 
and report local and Department-wide system security weaknesses has been implemented. 

• Cuirently working to establish an automated centralized self-assessment process using the Security 
Self Assessment Tool (SSAT). Current participants include: NIH, URSA, AHRQ, IHS, FDA, and 
AoA. 

2. Establish a comprehensive program to monitor access to the network, including controls over 
access to the mainframe and the network. 

• A Department-wide IT security program has been developed and implemented. Secure One HHS that 
incorporates Secretary Thompson’s One HHS Vision. 

• A Managed Security Service (MSS) using an automated intrusion detection tool to monitor, delect, 
and report local and Department-wide system security weaknesses has been implemenied. 

• Developed a cohesive and up-to-date set of HHS IT Security Policies. 

• HHS IT security has developed in-depth guides in 13 specific areas. 

• UFMS is nearing completion of its Security Test & Evaluation Plan, System Security Plan and 
Standard Operating Procedures that include the specific processes that will be used to monitor and 
maintain user access to the system. 

• URvfS will contain an automated feature to disable user accounts that have not been active for a 
designated period of time. 

• Verify that the UFMS project management staff has all applicable information needed to fully 
ensure a comprehensive security management program for UFMS. Specifically, this would include 
identifying and assessing the reported concerns for all HHS entities regarding key general control 
areas of the information security management process: 

3. entity-wide security planning, 

4. access controls, 

5. system software controls, 

6. segregation of duties, and 

7. application development and change controls. 

• A Department-wide IT security program has been developed and implemented, Secure One HHS that 
incorporates Secretary Thompson’s One HHS Vision. 

• A Managed Security Service (MSS) using an automated intrusion detection tool to monitor, detect, 
and report local and Department-wide system security weaknesses has been implemented. 

• Developed a cohesive and up-lo-daie set of HHS IT Security Policies. 

• HSS has progressively increased key system security metrics reported in the FISMA quarterly report. 
Key items for the 3rd quarter of 2004 included; 

o 96% of systems have been assessed for risk, 
o 95% of systems have security plans, 
o 93% of .systems have been certified and accredited 

• HHS IT security has developed in-depth guides in 13 specific areas. 

• UFMS has established end u.ser roles & responsibilities which are specifically designed to maintain a 
separation of duties 
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• UFMS has a detailed Change Control Management Plan that defines the process by which changes to 
documents, software, hardware, and infr^truclure must follow and the specific levels of approval 
required. 

• UFMS is using PMOnline to capture and track all change requests, issues, and risks. 

• UFMS is using TestDirector to capture and track all prc^lcms identified in the UFMS software and 
hardware. 


To help improve human capital initiatives the following 4 actions should be taken: 


1. Assess the key positions needed for effective project management and confirm those positions have 
the human resources needed. If needed, solicit the assistance of the Assistant Secretary for Budget, 
Technology, and Finance to fill key positions in a timely manner. 

• Staffing UFMS is a recognized at the program level as being a risk and is being addressed in 
accordance with our Risk Management Plan. 

• The Deputy ASBTF’s have been conducting weekly status sessions with UFMS program leadership 
that include human resource needs. 

• I (ASBTF) have contacted the leadership of the HHS operating divisions requesting their support. 

• Finalize critical human capital strategies and plans related to UFMS such as the: 

2. skills gap analysis, 

3. workforce transition strategy, and 

4. training plans. 

• Preparation of a Skills Gap Analysis, Workforce Transition Strategy, and development of Training 
Plans are complete for the CDC. 

• Instructor lead, classroom based training of the CDC workforce has been on going since June of this 
year (2004). 

• A COTS product, OnDemand is being used to provide desktop level learning aids for all UFMS users. 

• A Learning Lab has been established at the CE)C to enable CIX^ employees to practice and maintain 
what they have learned. 

• Skills Gap Analysis, Workforce Transition Strategies, and Training Plans for the FDA, and PSC are 
currently being worked on at various levels of completion as laid out in the UFMS project plan. 
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CORRESPONDENCE 
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the secretary OF health AIMD human services 
w>*a»*ir<eTOH. oc. 7«»ei 


‘JUN I 4 2001 


Memorandum to Heads of Operating Divisions aud Staff Divisions 


Subject: Unified Financial Management System 


In my May'25'’' memorandum on Workforee" Planning and Restructuring, I slated that ■ 
discussions have begun about moving toward “one HHS.” I defined restructuring to 
include specific actions for changing the way wc do business across the Department. The 
initiative to establish a unified financial management system is one of the efforts 
underway. 

The piapose of this endeavor is to achieve greater economies of scale, eliminate 
duplication, and provide better service delivery. Specifically, I have determined that the 
most efBci«it way of getting to the uiufied system is to have two modem accounting 
systems: one for HCFA and its Medicare contractors, and one serving the rest of the 
Department- These systems would be configured to provide unifoim, integrated financial 
information for all of HHS. 

While HCFA is continuing with its modernization effort, the NIH Business System 
(MBS), using Oracle Federal Pinancials, which NIH is in the process of implementing, 
will be the system that will be tailored and expanded for the Depanmem except HCFA. 
Therefore, 1 am designating NIH as Project Manager for systems implementation under a 
Department-wide Steering Committee comprised of Agency senior management and 
chaired by ASMS. NIH will also operate and maintain this system at the NIH data 
cemer. 1 am directing that necessary consultation with the agencies begin immediately to 
implement to NIH system and to ensure that this system meets the needs of the client 
agencies. 

Compared to multiple systems, my decision will reduce costs, mitigate security risks and 
provide timely and accurate information for management purposes. With the unified 
system, we will have uniform business rules, data standards and accounting policies and 
procedures across HHS, and a more efficient implementation as administrative support 
functions are incorporated. 

At the same time, I am directing that accounting services be consolidated by establishing 
a single accounting operation for HHS. This consolidation will help our restructuring 
effort to eliminate duplication of functions and provide belter service delivery while 
taking advantage of economies of scale under a unified financial management system. 
These accounting services will include, at a minimum, traditional accounting functions 
such as bill paying, voucher examination and travel voucher payment. We will also 
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Page 2 - Heads of Operating Divisions and StaffDivisions 


institute a process for considering opportunities for liimre consolidation of other accounting 
functions such as Agencies’ financial statement preparation and reporting. HCFA will be asked 
10 identify and participate in consolidation opportunities in other administrative areas that do not 
impact the need for HCFA to maintain its own accounting system that provides administrative 
and program support to the Medicare Program. 

A specific entity will be designated to serve as HHS’ central^^ounting operation. I will make 
that designation afler a cost and quality of service business case analysis of agency proposals has 
been completed. 

1 am directing the ASMS, as CIO and CFO. to coordinate with the Agencies to develop the 
unified financial management system and consolidate accounting services, and to ensure that 
plans arc consistent widi the workforce planning and restructuring effort 

I know I can count on your full cooperation with the ASMB on this very important aspect of the 
Department’s restructuring effort. 
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Today system testing continues and will continue into the first quarter of 
CY2005. Formal testing will continue through Friday October 8*. Formal 
testing of all functional components for the October release is complete. 
Several operational reports that became necessary with the modified release 
structure have not yet completed formal testing. User acceptance testing will 
be completed by October 14'*’. To date, formal testing has uncovered a total 
of 255 defects. Only 17 are still open and breakdown as follows (3 
accounting treatment, 4 COTS, 3 configuration, 6 UFMS code, and 1 potential 
enhancement). 

As expected, formal testing of UFMS identified defects in the overall system. 
When identified, our team categorizes the defect as a COTs package defect, a 
configuration defect, a custom code defect, an accounting treatment defect, or 
a potential future enhancement. I have included in the record two examples 
of defects uncovered during testing. 

On August 31st, while executing scripts IT. 6.20.1 “Import modified converted 
obligation”, the testing team noted that the obligation workflow was not 
performing as expected. They entered DR #336 into the defect tracking 
system and notified the implementation team of the defect. Detailed 
investigation determined that the cause of the problem was a defect in the 
COTS software. The team filed the defect with Oracle who entered it as TAR 
#3970288.996. Oracle is in the process of correcting the defect. This 
capability is included in the April release. 

On August 18*'’, while executing script IT.33.0.0 “Protection of data” the 
testing team noted that ID masking was not working properly. They entered 
DR #304 into the defect tracking system and notified the implementation team 
of the defect. Detailed investigation determined that problem was a defect in 
a portion of the UFMS custom code. The UFMS technical team corrected the 
problem with 5 hours of effort and submitted it for retest. The retesting 
completed successfully on August 26*. If this defect had not been detected 
until deployment the ID field would have been visible to users of the system. 
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Mr. Platts. Thank you, Mr. Weems. Again, my thanks to all 
three of you for your testimony here today and your written testi- 
mony. 

Let me start, Mr. Weems, maybe where you left off in talking 
about risk-taking and the decision and approach you are taking 
being schedule-driven. In your testimony I think or your response 
to GAO, you suggest that the title of their report should have been 
better titled, “Aggressive Schedule Increases Risk of Implementa- 
tion of HHS’ Financial Management System.” In making a decision 
for risk-taking, there is a cost-benefit analysis. 

What is the substantive benefit to be achieved? I assume it is 
getting the system in place quicker. But what was the cost-benefit 
that was done in taking what you acknowledge to be greater risk 
to be schedule-driven as opposed to event-driven? 

Mr. Weems. Thank you for the question, Mr. Chairman. In mak- 
ing that calculation, I think we looked at several things. First, we 
had a coalition of the willing who were ready to sit down and work 
enthusiastically on a project whose concept had already been prov- 
en at NIH. We had a group of people who were willing to work very 
hard in making this implementation happen. Our contractor, 
BearingPoint, uses a schedule-driven model as their best practice 
in implementing these systems. 

Now, I would not say that we are exclusively schedule-driven, 
Mr. Chairman, and Mr. Steinhoff and I had the opportunity to dis- 
cuss this beforehand. If we were purely schedule-driven, we would 
have not considered the empirical data we were getting from test- 
ing. We would have gone ahead with an October implementation. 
Instead, we were able to accomplish a tremendous amount of work. 
All of that work is still preserved. 

Much of the system that will be implemented in April, that work 
is done. We are in the testing phase. I would say we simply ran 
out of runway to be able to achieve what we were going to achieve. 
We had a good test plan. We simply were not able to complete test- 
ing on time. Given that, we decided to pull back certain pieces of 
our implementation and implement what we were rock hard solid 
on. 

So I would say the calculation that we made was to leverage the 
enthusiasm and know-how that our employees were willing to put 
to it. And frankly, Mr. Chairman, after 23 years in the Federal 
Government, I have seen projects that are not schedule-driven 
stretch out and become careers for people. 

Mr. Platts. Let me follow that up. I certainly believe the accu- 
racy of your statement — of the team you have and being committed 
to your efforts, and I am also grateful for their efforts and believe 
you and all involved in moving this daunting task forward should 
be commended, and I certainly share that. In your testimony, 
though, when you were making the decision up front, you talk 
about the team and the confidence and the enthusiasm, but in your 
testimony you said, “Three years ago most HHS employees im- 
pacted by this business transformation had little confidence in the 
system. Today, many employees have already learned how to use 
it.” 

It does not seem like there was that level of confidence when you 
were making that risk assessment and decision up front. It seems 
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like there was not yet a buy-in other than at the senior manage- 
ment level. Can you expand on that? 

Mr. Weems. Sure. And that is a very good question. I think that 
at the initial inception of almost any change people are very skep- 
tical. The Secretary himself is a leader of boundless enthusiasm 
and that enthusiasm is highly infectious. I think what we did — and 
if I could have that chart — one of the things that we have done on 
this project is to make sure that we went out and we touched peo- 
ple with this. 

We had rapid early adoption where and when it was time to 
start selling this project, my predecessor and then, later, I went out 
on the road, met with every operating division head, met with each 
one of the agency CFOs and CIOs and said this is the direction 
that we are taking. I think that we were able to make a case that 
as they looked at their financial systems, which I think they would 
readily admit are held together with duct tape and baling wire, 
that they said this is the way to go and get me there now. 

Mr. Platts. The other aspect of my question on the risk assess- 
ment or cost-benefit analysis is, again, not what resources or 
strengths you had going in, but why take higher risk? What will 
we see in the end be the benefit of greater risk, assuming we can 
avoid those risks? 

Mr. Weems. Well, the benefits of the project, first of all. And I 
think those benefits have been clear from the outset. Right now, we 
pay bills all over HHS. We do not need that redundancy. We need 
to get to those benefits as quickly as we can. And it is not paying 
bills or booking accounts receivable. Those are things that I have 
functional responsibility for. 

The thing that I have direct responsibility for, providing the Sec- 
retary, Members of Congress, and others information about the fi- 
nancial condition of HHS, I find that to be a very frustrating expe- 
rience right now where we are. I want to get to the end. I want 
to be able to inform this committee, the President, the Secretary 
about some simple things about our programs and others more 
complex about the condition of finance in HHS. 

Mr. Platts. Was there, I know some of this is really in relation 
to your predecessor, and I am asking you 

Mr. Weems. I am still responsible, sir. 

Mr. Platts. I am asking you to draw from your predecessor. But 
I agree, the sooner we can achieve your ultimate goal, the better 
for everybody, and most importantly for you and all at the depart- 
ment making day-to-day decisions, and that serves then all of our 
citizens that your department works with. 

Was there a calculated decision that if we take this approach to 
implementing the system, which is not what we are really focused 
on but how we are ensuring the implementation goes well, was 
there a decision in taking a schedule-driven approach we have 
higher risk than if we take an event-driven approach, but we can 
do it in 2007 instead of 2009? There must have been a timeframe, 
that if we take a more cautious, less risky way, it is going to take 
longer. That is my assumption. 

Mr. Weems. I do not have a lot of insight into where that process 
would have driven us. I am afraid that is one thing that I do have 
to say that I probably do not know precisely how the decision- 
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making was done. But I would say, and, again, something for 
which I stand responsible, those alternatives have been presented 
to me as I have managed this project. 

In February, when we knew that it would require perfect execu- 
tion, I asked what the alternatives were. Those were clear — we 
would have to delay certain things, it would stretch out the time 
when HHS would be fully JFMIP-compliant. I took a decision that 
I did not want to do that, that I wanted to stick with schedule. The 
same thing in May. When we got to August, we had pushed the 
project I think as far as we could. We had gone through testing and 
the empirical metrics at that time said there are some things we 
can do and some things we cannot. 

So we are going to do those things that we can do. Those things 
that we cannot, we have completed substantial work on. That is 
done. I think if we had pulled the project back, we would be in the 
same place we are today except for those things being done. We 
could do general ledger and payroll for CDC except we would not 
have all of the other functionality that we have virtually ready to 
go in the test phase right now. We would be working that through 
until April. So I would say we are much farther ahead of the game. 

Mr. Platts. I want to followup on that a little bit. But I want 
to give Mr. Steinhoff a chance to comment on the decision. In your 
experience with various agencies, the additional risk, that HHS ac- 
knowledges in taking this approach, is your experience that taking 
a less risky event-driven decision would have added a great 
amount of time into the expected completion? 

Mr. Steinhoff. No. Basically, what we find are things fairly 
similar to what we saw at HHS — the folks are very committed to 
the project, they work very hard. There is no question about that. 
What we find is that there is such a desire to go on line with a 
new system that people do. And what typically occurs, they have 
problems in developing all of their requirements and they have 
testing problems. 

And that is what happened basically at Interior a few years ago, 
that happened at NASA. They did not have metrics, they did not 
have ways to really look at their performance in specific terms. 
They had not defined every requirement. 

HHS has I think something like 2,100 requirements. Many, prob- 
ably most, are defined. Some are not. You have to define well what 
environment the system is going to be in, configuration manage- 
ment, integration. You have to test to try to find defects, and have 
very clear measures as to how many defects are acceptable. What 
we typically find when someone is date-driven, and oftentimes the 
beginning of the fiscal year is that magical date so the agency can 
have a complete fiscal year, they make that choice to roll out the 
system to meet the date. 

And, typically, the problem falls into two areas; and that is, prop- 
erly defining all the requirements and testing. A COTS package 
will do a lot for you, but there are other things one would need. 
One needs to know how the system is going to be applied in their 
environment, how it is going to be implemented, how is it going to 
be used by the user, what is the expected performance. 

This is a huge endeavor. Mr. Weems stated it was one of the big- 
gest ever. You are talking about three-quarters of a billion dollars 
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based on the present estimate. Basically, in our view, event-driven 
is really the way one should go. That does not mean you do not 
have a schedule, that you do not try to hold people’s feet to the fire, 
but you assure you do not consider a step completed until that 
event has been proven to be successful, that you have determined 
that you have satisfactorily defined all of your key requirements, 
you have determined that you understand how the system is going 
to work, and that, whatever the environment the system is in, you 
have determined how interfaces with other systems will work. And 
to us, that is the way to approach these projects, especially one of 
this magnitude. 

If you look at the views that we have, they are very similar to 
the IV&V. They have questioned requirements. Certainly along the 
way the IV&V has found requirements are better defined, but they 
have questioned the specificity of many requirements, whether they 
are ambiguous or not. It is hard to test against that. The IV&V had 
a fairly extensive critique of the testing, not just that the system 
was not quite ready to pass the test, but it raised concerns with 
planning for the test, how the test was conducted; it was really 
soup to nuts. They talked about the deterioration of some of the 
documentation in the latter stages before October 1st. That typi- 
cally happens when people are under tremendous pressure to push 
something out by a given date. Short-cuts occur and you end up 
having problems. 

What is difficult to say at this time, Mr. Chairman, is ultimately 
what will happen. No one has a crystal ball. And there are folks, 
I will acknowledge, that maybe do not follow a disciplined process 
and things work out for them. Others might follow disciplined proc- 
esses but some things go awry later on. 

But our belief is, and a very strong belief, that you should always 
be safe on these projects and that disciplined processes have been 
proven to be the way to go, and event-driven is what people really 
have found gives you the best chance for success. 

We have a chart on page 15 of our report, a figure that shows 
what typically happens when all the key disciplines are not fol- 
lowed, or not followed substantially. You have a lot of visible 
progress in the beginning — again, you cannot always tell what your 
progress is because you have not really had the metrics in place to 
measure it well. Where you run into the problem is when you get 
to the end. And the real proof of the pudding for HHS will come 
sometime in 2007. 

The goal that we have is really to provide our best thinking at 
this stage in looking at this project, given the fact that HHS has 
more time before project completion, and say here is what we think 
you should be doing now and here is what you should do to go to 
that next step. So, we feel strongly that event-driven is the way to 
go. But, again, only time will tell how this will turn out. 

Mr. Platts. Let me expand on that approach. Mr. Weems, in 
talking about your decision to delay the October implementation 
plan, you said that in February there were kind of some early 
warning signs I guess. 

Mr. Weems. Yes. 

Mr. Platts. And your team said you would have to be perfect, 
but you think you can be perfect and go forward. Then in May, it 
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is going to take a heroic effort, but we are going to make that he- 
roic effort to get it done. In August, IV&V comes back with I guess 
some more concerns about the ability to really do what you are 
planning. And then here in late September you make a final deci- 
sion to not go forward. 

I guess two aspects. One is, what is the likelihood you would 
have gone forward and tried to fix the process as you went forward 
if the GAO report was not coming out which added some pressure 
or scrutiny? And I would appreciate a frank dialog on that. And 
second, if you had back in February 20/20 hindsight, I openly ac- 
knowledge that, would the delay — right now you are looking at a 
6-month delay is my understanding. 

Mr. Weems. Yes. 

Mr. Platts. So talking next April I guess, maybe May. 

Mr. Weems. April. 

Mr. Platts. Would it be April or May to be where you think you 
can go forward if you had not been driven by the October date, the 
schedule being October? I think I am paraphrasing this well, that 
if it was event-driven, you would say we are not worried about Oc- 
tober, worry about just dealing with what we need to do right, and 
so we would have made changes back in February. Do you think 
you would have been delayed until April if that had been the case? 

Mr. Weems. Sure. But let me take your first question first, and 
that is the events leading up to the decision that we took. I got the 
alert from the IV&V contractor. I get reports from them every 2 
weeks, but from time to time they will issue a special alert, and 
that is what this was. It was outside of the normal process. It is 
something that says, Mr. Weems, you need to go pay attention to 
this now. 

Obviously, I knew that our friends at GAO were looking at us. 
Though their engagement with us had ended at that point, I cer- 
tainly was cognizant of their presence. But I would say that alert 
itself had some very discreet recommendations in it. We had just 
finished our readiness review, so there were some objective meas- 
ures. 

I sat with the team leaders down there, spent a good part of the 
day with them going through at a very granular level where are 
we, where are we, where are we. And as they looked at the 
empirics coming out of testing, as they looked at the amount of 
testing being done, there were a couple of things for which they 
could not offer me assurance. And I would say that in my mind 
those were the things that made up my mind. 

I was not offered complete assurance of funds control by the time 
that we would turn the system on. That as somebody with dele- 
gated responsibility of CFO, I knew at that point we could not do 
it until I had that assurance. 

The second piece was there was some question as to whether or 
not we would be able to pay bills timely. Causing consternation 
among our community to which we pay bills is not something that 
I was looking forward to. We had already, I would say, engaged 
that community to start telling them that there would be a 2 -week 
delay in bill paying as we switched the system. Well, I was not 
going to let 2 weeks stretch into 3 weeks, stretch into 4 weeks. 
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And so I would say at that time I stepped back and I said, OK, 
we cannot go forward with full functionality. What can we do? And 
the team quickly came up with those things that had been rock 
hard in implementation and testing, general ledger, payroll, and we 
could get to grants. So those are the things that we decided to im- 
plement. So we went forward with an implementation, but those 
things that were not rock solid we pulled back. 

To answer to your second question, sir, in talking to my team in 
February and in May about, OK, if we have to do something here, 
what would we do, a good deal of the advice that I was getting 
would say that we would have delayed for a year from October 
rather than to April. So I think taking the steps that we took, we 
got a lot of work done between February and September. The step 
that we took at the end of August and beginning of September now 
allows us to reflect on that work, to subject that work to testing, 
to implement it in April. 

Mr. Platts. OK. Clearly, the empirical data associated with the 
testing played a big role in your decision. 

Mr. Weems. Yes. 

Mr. Platts. That would seem to make a strong case for what 
GAO argues of the importance of having more clearly defined 
standards, the requirements management up front, a tighter ap- 
proach up front than a more flexible plan. It seems like you have 
had an example of that now. Is that going to cause you, along with 
the report in total, to look at maybe the need to revise some of your 
requirements now before you keep going forward? 

Mr. Weems. Well, I think we are going to try and do both at the 
same time. We have accepted a number of the recommendations 
from GAO, and certainly we are grateful for their help in that re- 
gard. So with those revisions, I do think we are positioned to con- 
tinue the project, continue pace and tempo, and to continue to 
measure how we are doing with objective measures, but to keep 
that April date in front of us, too. 

Mr. Platts. Maybe a followup that kind of relates to how defined 
your standards are up front, your requirements up front. As I read 
the testimony in preparing for today, a big part between HHS and 
GAO is the different mindset with using a commercial off-the-shelf 
product. And your contention is that because you are using that 
COTS, you necessarily cannot be as defined as if it was a cus- 
tomized plan or product. GAO, your history with other departments 
and things, yours is that even with using a COTS system, there 
still needs to be more specifics than HHS is approaching. 

Mr. Steinhoff. Yes. 

Mr. Platts. Mr. Steinhoff, if you want to expand on that, and 
I guess, specifically, you mentioned Interior. In your review of 
other departments and agencies that have undergone these efforts, 
I guess one thing is maybe address the difference in your belief 
that it should be more defined even though it is a COTS; and then 
second, is there a history of other agencies that have used a COTS 
product and thus thought they had to be less specific, but then in 
the end they had problems and we get into the rework and the cost 
of that? 

Mr. Steinhoff. Yes. Let me kind of talk a little bit about the 
philosophy behind COTS, and to say at first that I serve on the 
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JFMIP steering committee. I had chaired the committee for several 
years and I am now a member, been on it for many years. 

What this process is about, this certification process, is the Gov- 
ernment was buying commercial packages, working with vendors, 
doing a lot of customization. And the Government stepped back and 
said let us lay out what our requirements are, our core require- 
ments. There may be A to Z specific requirements, and for an en- 
tity such as HHS there may well be many others. There are also 
mandatory requirements and value-added requirements, more 
value-added are becoming mandatory as time goes on. 

But what the government basically said was let us have a proc- 
ess in place to look at commercial packages and to really make 
those packages meet a certain level, certain standards. We will de- 
fine the requirements and we will test against those requirements. 
And at each step of the way, I think the testing itself has become 
more robust and more complete. 

You have 331 requirements that are now tested by JFMIP and 
they are tested in a controlled environment, one environment, 
1,500 transactions. COTS packages are not tested in HHS’ environ- 
ment, or Interior’s environment, or NASA’s environment. They 
might be configured differently. The systems might work a little 
differently and have different functionality you can turn off and on. 

The issue of how precise you have to be in your requirements 
really comes after you purchase the package. As you are making 
your decision on purchasing the package, you can be I think more 
general; what does this do for me, and how does it roughly do it. 
And then the key, as Mr. Weems said correctly, is to then adjust 
your own processes to meet that system. There may be some areas 
where you do not. And there is probably no COTS package that is 
not customized in some manner. I am not sure exactly how many 
of these are going to be applied later one, but I think HHS had 
something like 2,100 requirements identified at the time of our 
work and the core functionality tested in the COTS package was 
331, or about 15 or 16 percent. 

So, once you have purchased the package, you have to sit down 
and really define exactly how it is going to be configured, you are 
going to have to look at the suitability, you are going to have to 
define how you want that requirement to work for you. And that 
is pretty much accepted practice. The JFMIP makes very clear on 
its Web page that these are things that you have to do. You have 
to test this in your own environment. You have to determine how 
you are going to use the functionality and determine the require- 
ments. 

And really looking at the methodology selected by HHS — and I 
will add that our differences with HHS is not so much with their 
methodology, it is in how far they have gotten along in the meth- 
odology; you know, the metrics or the rigor to it. HHS’ methodology 
spoke about reviewing and updating requirements for design proc- 
ess workshops, establishing baselines, performing fit and gap anal- 
ysis, developing gap closure alternatives, creating final baseline re- 
quirements. 

We think those are proper things to do. What we and the IV&V 
contractor found were a number of requirements that were not yet 
specific enough to really even know what you were going to get 
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from that requirement, to actually develop a test script to test it. 
So it was really a matter of more needed to be done. 

But regardless of whether you have a custom system, which we 
do not recommend people develope, the way to go is to buy the 
COTS packages, or whether you buy a COTS package, you still 
have to work hard on the requirements or you will get to the end 
and the system will not be able to do some things that are essential 
for you. I will give you an example at an agency that had really 
struggled with a COTS package because of the liability to readily 
process the transactions it has. 

GSA, which has a high volume of transactions, found that the 
number of steps the software went through took too long. It is 
called scalability. And the way the software was designed, it was 
not set up to operate efficiently in GSA’s environment. GSA found 
that out once it turned on the switch. The agency spent a lot of 
time and effort to work through that. The key is to identify prob- 
lems before you turn on the switch, long before, and make those 
changes early on so you do not face the rework later on. Rework 
is where you spend a lot of money. 

Mr. Platts. Mr. Rhodes, did you want to add anything regarding 
the approach and those standards or the specificity of some of the 
standards for which you have asked for more? 

Mr. Rhodes. I guess I would get back to the discussion on risk 
that you were having earlier. Mr. Weems is revolutionary. He is 
wanting to completely change. He is wanting to enact what the 
Secretary wants, which is to transform Health and Human Serv- 
ices. By definition, that is risk. As he stated, largest budget, widest 
and most diverse portfolio, etc. 

I do not think, based on my having looked at the JFMIP require- 
ments, I do not view that as a revolution template. That is ulti- 
mately a partial calibration of an accounting system. What Mr. 
Weems wants to do is revolutionize financial management at HHS. 
That is the correct thing to do. 

But, with that in mind, then if I am going to establish cost as 
an independent variable and I am going to say there is $700 mil- 
lion and I am not going to break this budget, and I have the con- 
straints of making certain that I pay the contractors and pay the 
bills of HHS on time, I have the operational requirement, and I 
have 110 systems that I have to interface, the concern that I have 
is that when words of perfection or heroic or Herculean effort and 
things like that are brought in, then I have to view it as risk. 

In looking at it through risk, day 1, event-driven or schedule- 
driven, there is a great deal of rigor and specificity required for 
success. The fundamental difference between event-driven or 
schedule-driven is emphasis. The date is more important than the 
function, or the function is more important than the date. That is 
really the only distinction. 

So, if I take Oracle’s view, or PeopleSoft, or SAP, or whomever, 
I take Oracle’s view of the universe, well, their having a market- 
centric view to get the JFMIP compliance, but they may not know 
anything at all about HHS. Fine. That means the onus is on HHS 
to do the gap analysis between how do we do things now and what 
does this bring to the table so that we can get the delta in place 
so that we can understand what we have to test for. As Mr. 
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Steinhoff said, what is critical, what is not critical, what can be de- 
ferred, what cannot be deferred. 

The real challenge that I see for them is making certain that 
there is that, as I described for you last time when we were talking 
about the Department of Defense, that crimson thread of salvation 
that runs through this requirement set. It leads from concept of op- 
erations directly to large scale requirements bounced against the 
system that we are procuring, then you start getting down into the 
detailed requirements, and from that, we are building the test case 
that comes back and proves that the system actually does this. If 
that is in place and supports the schedule, then being schedule- 
driven is not bad because your requirement set is strong enough 
to say I believe my schedule. If it requires perfection, then I better 
have perfect requirements. 

I am not trying to be tautological here. But the onus, the pres- 
sure is on to be absolutely correct and be correct the first time out 
of the can. And when your effort is already heroic because you are 
trying to transform something as large as the financial manage- 
ment at Health and Human Services, then the requirements had 
better be strong and they had better be precise, because there is 
going to be some work you have to do and if the ultimate changes 
you make to the system are greater than 25 percent, then you have 
just expended the same amount of energy you would if you had 
started from scratch. 

And those are the things that need to be understood and you 
have to be collecting the metrics that let you know where you are. 
For example, it is not a matter of defect tracking, it is a matter 
of trend analysis — what problems am I encountering in this devel- 
opment cycle and am I getting better, is the number going down, 
are they able to bundle together, things like that. That is the kind 
of quantitative measures that provide you the trend analysis to 
know where you are headed. But they all come back to the stabil- 
ity, veracity, clarity, lack of ambiguity in your requirement set. 

Mr. Platts. The fact that we have the five legacy systems and 
the 110 or so interfaces, and just the breadth of the whole trans- 
formation is part of that argument of why the greater detail up 
front? 

Mr. Rhodes. Absolutely. 

Mr. Platts. Mr. Weems, I want to reemphasize if I did not say 
it earlier, we want you to have great success by 2007 so we can 
move you over to Defense and then replicate the success there. 
[Laughter.] 

Because a $400 billion budget will be nothing after we succeed 
with $580, right? 

Mr. Weems. That is right. 

Mr. Platts. I had a number of points to followup on. I want to 
have everyone engaged in the dialog here. Mr. Weems, earlier you 
talked about, in taking the approach you have, a schedule-driven 
model, that it was BearingPoint’s approach, that is their best prac- 
tice. Was that a big part of the decision to go this way versus the 
approach that GAO has recommended, because BearingPoint being 
your contractor and you are trusting them once you make that de- 
cision that they are who you are in the battle with and their belief 
that this is best practice? 
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Mr. Weems. That certainly did bear on it that our partner was 
also engaged in this effort. I would also say the Oracle model fol- 
lows the same type model as best practice for implementation. That 
was important, but I think the thing that makes us look to sched- 
ule is the benefits of the system, is having Federal managers across 
HHS look at what they have now, believe in the possibility of the 
future and say Kerry, get me there now, get me there sooner, I 
need that. I think that is the thing that drives us. 

Capturing those benefits, having Federal managers understand 
where they are financially in an enterprise that is over half a tril- 
lion dollars a year is absolutely essential, and that is where our 
managers want to be. That is why they are saying get me there 
now. 

Mr. Platts. I would think you would agree that enthusiasm is 
great and that buy-in is so critical. But part of your role is to see 
the whole picture and, you know, we want to get you there but 
maybe — and I will say it in the way as a parent might sometimes 
with kids. We could be going to the park and they want me to 
hurry and get them there because they want to get playing. But 
I have to stay within the speed limit, because getting them there 
as quickly as I can but safely is something that is my responsibil- 
ity. And part of your role is to take all that excitement, enthu- 
siasm, buy-in, but make sure it is still going to be at the end of 
the day truly the most responsible approach. 

Mr. Weems. Absolutely, Mr. Chairman. I think that was the role 
that I and my leadership team played at the end of August and 
early September is that we stepped in, looked at where things 
were, and said we are not ready. We took an affirmative manage- 
ment action. 

And when I took that decision, I immediately conferred with my 
leadership team and then we went right down that pyramid that 
I had up earlier. We talked to the managers, we told them where 
they were, and they were very accepting. So we took the decision 
that was appropriate at the time. If I and my team had taken no 
action, we would right now be hurtling toward full implementation 
starting tomorrow. 

Mr. Platts. You certainly have appropriately emphasized the 
importance of all personnel buying-in and being part of this team 
effort. Can you address the issue of your staffing, that is one issue 
GAO has raised, and your having staffing that you need to move 
the ball forward in an appropriate fashion? 

Mr. Weems. Yes. And that I certainly will admit from the begin- 
ning has been a particularly nettlesome issue because of the predi- 
cate from which we began, and that is that we were not going to 
build permanent Federal bureaucracy to implement this. That we 
were going to bring in a few key people, the rest of the Federal ef- 
fort has been comprised of folks who have been detailed in from the 
agencies to fill roles. 

Those details work for 6 months, in some cases a year, and then 
the agency needs them back. Other roles, especially in the site im- 
plementations, have been filled by people doing double duty, where 
they do their day job and then at 6 in the evening they go do their 
UFMS work. That is sort of a test of some of the dedication of the 
staff They have worked very hard to do that. 
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Looking back, we probably should have opened up a couple of 
more permanent positions, if I had to say what would I have done 
differently. For the positions that we have that have been opened, 
we have offered temporary positions — why not come in, we will give 
you 2 years’ worth of work, after that we are not sure what hap- 
pens. We have not had particularly good luck in filling those posi- 
tions. So I would say, as GAO notes, our overall human resources 
strategy is something that we need to take a step back to look at. 
We need to make sure that we have those positions filled with 
good, competent people. 

One of the benefits though that we think that this strategy of 
using detailees and folks from the agencies is it cuts down substan- 
tially on our training costs. If somebody comes and works on the 
project for 6 months, for a year, and then goes back to the agency, 
they not only going to be fully trained, they are going to be a super 
user. When the system comes up they are going to say, hey, I 
worked on this project, I know how to do this. We think that is one 
of the benefits. We understand that we have some key vacancies 
and that certainly is something that we are going to have to spend 
some time working on. Hiring a Federal employee is very hard and 
the process is not particularly nimble. 

Mr. Platts. I am glad to hear that acknowledgement — that you 
are actively looking at your human resource issue and how to ad- 
dress the challenges you are facing there. When I hear the heroic 
efforts and dedicated effort being put forth as you try to move for- 
ward to your October deadline, that is great. 

But when I look and think we are basically on a 5-year plan and 
3 years more to go, the ability to maintain that tempo without 
burning out key people and in the end losing that wealth of knowl- 
edge is something that we need to be careful of And the fact that 
you are looking at how to correct that is good. And in this case I 
imagine you would like to have what DoD has, which is some hir- 
ing flexibility so that you can more quickly fill spots that you need 
as opposed to the bureaucratic process that takes a while. 

Mr. Weems. I am also worried, though, about creating a perma- 
nent bureaucracy. Having three or four people, five people, a nu- 
cleus around which we can work I think is important. But in my 
23 years in Government, sir, I have seen a lot of project offices turn 
into things that live well beyond their useful life and draw re- 
sources from the Government that they should not be drawing. And 
that is one of the things that we have tried to be careful to avoid. 

Mr. Platts. Yes. Because once we create a position, it stays. 

Mr. Weems. Yes. 

Mr. Platts. Create a program, it stays, even if it out-lasts its ap- 
propriate use. 

We have been joined by Mike Turner, a member of the commit- 
tee. Mike, I appreciate your being with us. Did you have anything 
you wanted to say? 

Mr. Turner. I just appreciate the chairman’s continued work on 
this issue. 

Mr. Platts. Thank you. Let me talk about maybe some of the 
cost issues. With that three-quarters of a billion dollar estimate out 
there, I guess the testimony had information about the CDC pilot 
implementation, that NIH pilot, and that was about a $100 million 
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cost using the same COTS system and about $12 million to migrate 
that system over to the UFMS. 

Mr. Weems. Yes. 

Mr. Platts. I guess the first question would be, why the $12 mil- 
lion cost to migrate it over? And is that $100 million part of the 
$700 million? 

Mr. Weems. Yes. 

Mr. Platts. OK. That is good. I was hoping it was. [Laughter.] 

Mr. Weems. So is the $12 million. 

Mr. Platts. And the $12 million is? 

Mr. Weems. Yes, sir. 

Mr. Platts. Why, if it is the same COTS? Kind of educate this 
lay person to understand that. 

Mr. Weems. It is an excellent question. When we started back in 
June 2001, the five systems that we were looking to replace were 
not in the same place. NIH was much farther along. Also, NIH’s 
system brought to the table other administrative functions beyond 
financial management. 

Our choice at the time was to use the NIH system as a model 
for the rest of the department. But their work was not scaled right 
for the rest of the department, their effort was not scaled right. So 
that did not seem like a viable alternative. Our other alternative 
was to stop NIH from what they were doing, delay the benefits of 
their implementation, and let the rest of the department catch up. 

The third way was to let NIH proceed, let the rest of the depart- 
ment catch up, and at some later point merge the two implementa- 
tions. That latter choice is the choice that we made. The $12 mil- 
lion cost, that is an estimate right now of what it will take. But 
the NIH implementation proceeded in a way to meet NIH’s needs, 
not the needs of the broad HHS. That $12 million is the cost of 
bringing those two things together. 

We think we made the right decision. Right now, we closed the 
books today. NIH is going to do financial reporting this year on its 
system. We did not want to delay that. NIH has a very efficient 
and effective e-travel system, way ahead of the rest of the depart- 
ment. We did not want to delay that. They are going to have other 
administrative functions like supply chain management. We did 
not want to delay the benefits of those things. 

So, the short answer is, NIH developed an implementation for 
NIH. We allowed them to proceed. It meets their business needs. 
We will catch up with them this next year as we bring their busi- 
ness needs into UFMS and align their project with UFMS. 

Mr. Platts. Mr. Steinhoff, in your assessment of that approach 
and kind of the focus on the cost issue, is that $12 million estimate 
of integrating it over something that seems viable, or is it going to 
actually be more? 

Mr. Steinhoff. We did not actually look at that at all. I would 
say though, Mr. Chairman, it gets back to our earlier discussion 
about COTS packages. Mr. Weems said it very well, that package 
was taken and configured for NIH. So, for every COTS package, it 
is very important that you configure it for your use and you deter- 
mine how functionality is going to be employed. 

So it is not surprising that HHS would have to make some 
changes to take the NIH package into the broader parameters here. 
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Also, as the department better defines its requirements, it may find 
other things are needed to assure that the NIH system is in fact 
meeting the broader needs. For example, the COTS package is pri- 
marily core accounting, whereas the vision is much broader. 

So, we did not look at the estimate. But these are the kinds of 
costs that one would have, and it is not surprising to incur a cost 
to convert the same COTS package to another environment. 

Mr. Platts. Mr. Weems, in talking about where you were with 
NIH, you touched on something that I was going to raise about the 
legacy systems. In June 2001, when the Secretary’s memorandum 
came forward that HHS was basically going to have one — great vi- 
sion and commendable effort that is going on — ^various components 
of HHS were already moving forward, like NIH. What is the status 
of those others? Have we continued to spend money elsewhere? Or 
were the other ones pretty much put on hold and are part of the 
big picture? 

Mr. Weems. That is right. 

Mr. Platts. OK. 

Mr. Weems. In fact, Mr. Chairman, I remember this meeting 
very, very clearly with the Secretary. In February, just after he 
was confirmed, we sat down and we started working through the 
budget with him. And in CDC, in FDA, in PSC, in NIH, there were 
budget requests to build five different accounting systems. He 
looked at us and essentially said why are we doing this. Let us 
have one. 

And that led to that memorandum. That budget meeting in Feb- 
ruary led to that memorandum. So since then we have done main- 
tenance costs on the legacy systems to keep them going. But we are 
not building systems outside of UFMS. We absolutely put an end 
to that. 

Mr. Platts. That is great and glad to hear that. Do you by any 
chance remember, ballpark, what those estimates were if you had 
gone forward with those independent efforts to rewrite them? 

Mr. Weems. No, I do not remember the total project costs of each 
incremental budget cost or what we were looking at at that mo- 
ment. I do not recall. But the thing that they were doing were sim- 
ply buying new of what they had. There was not the vision in the 
agencies of being able to go to a shared service environment and 
say we are going to have one place in HHS that pays bills, and 
guess what, guys, we are going to compete to see who gets to do 
that. We are going to have one place that maintains the system, 
we are going to have one place that has a Help Desk for all of 
UFMS. That vision was not present in those budget requests. That 
vision was present in June. 

Mr. Platts. And that is something with your vendors, all the 
private sector, that has to be something that they look forward to, 
I would think, that there is one place that pays bill so they know 
who to go to between the various entities. 

Mr. Weems. I am sure our partners look very much forward to 
that, and certainly those of us who have to track financial trans- 
actions across the institution do too. 

Mr. Steinhoff. Mr. Chairman, if I may add. 

Mr. Platts. Yes. 
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Mr. Steinhoff. I will add that concept is one that we support 
strongly. I think Mr. Weems got to the bottom line of the issue in 
actually making that happen when the Secretary said you are not 
going to spend the money. You probably remember when we testi- 
fied on DOD, we said part of the problem is the military services 
and other commands still have their own budgets and still have 
their own constituencies through appropriations and are building 
away. You have to control the money. You have to provide that dis- 
cipline. And this approach is one we strongly support. 

Mr. Platts. And it is a good model for other entities like DOD 
to follow. 

Mr. Steinhoff. Yes. 

Mr. Platts. And for Mr. Weems, for you at the department head- 
quarters and ultimately for the Secretary to have that knowledge. 
In our hearing in this room not too long ago with NASA, the CFOs 
are dedicating their efforts, but those independent NASA Centers 
are kind of going their own ways. 

Mr. Weems. If I might make a point there, Mr. Chairman. We 
did not create a single budget for UFMS. The budget for UFMS is 
in every one of our operating divisions. They have a stake in the 
success of this project and they have not gone off with that budget 
and hired somebody else and said this is crazy. They have seen the 
benefits, they have stayed with us, they are using dollars appro- 
priated to them, and we bring it all together through a Memoran- 
dum of Understanding in a central pot to expend it. But those dol- 
lars are appropriated to them and they have stewardship of those 
dollars. 

Mr. Platts. Good approach. How about on the issue, as you 
move forward with your implementation, the need for manual ef- 
forts to really address shortcomings in the program that were not 
envisioned? What do you expect with CDC as you go forward? 
What is likely to be the level of manual operations or processes 
that are going to be required to make up for something that was 
not envisioned? 

Mr. Weems. Well, the short answer is, a few. There will be some. 
But that I think follows the rule that you have to give a little to 
get a lot. 

Mr. Platts. Are there some specifics, some examples that maybe 
you envision? 

Mr. Weems. Oh, yes. Most of these actually have to do with ex- 
isting interfaces that are going to be manual transactions now that 
will not be automated in the initial implementation. International 
invoices, how we pay our partners internationally, that is a fairly 
small workload, one that we did not think was worth writing an 
extension for. E-mail notification of purchase order exception proc- 
essing, this purchase order did not work so we are going to send 
you an e-mail and tell you, we will have to have a manual work- 
around for that. CDC has an interactive voice recognition system 
that they use for some vendor payments, and we will have a man- 
ual work-around for that in this implementation too. 

So there will be a few. We think that actually these will be taken 
care of in subsequent releases of UFMS. But there will be a few, 
and I am afraid I do not have any example with me, where writing 
an extension to the software just was not worth it and so we are 
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going to adopt the business change that using Federal Financials 
brought to us without writing an extension to do something manu- 
ally. These will be small things where it just was not worth the 
dollars to write the extension for the software. 

Mr. Platts. Mr. Steinhoff, is that something, I am not sure how 
much detail you looked at, that likely manual work-arounds are 
going to be required? Anything you want to add? 

Mr. Steinhoff. Well, they had not actually rolled out the system 
so you could not really see exactly what would be entailed there. 
It has been a problem with other agencies who have found that 
their system does not provide them what they need. So the staff 
immediately goes off and develop an ad hoc system or end up with 
1,000 Excel spread sheets and they pull down data, or at times peo- 
ple find that the information is there but it is not there in a form 
that is easy for them to use it. So the performance of the system 
and the ability to meet the users’ needs is lacking. But HHS was 
not yet in a position that we could tell what would happen. And 
you really tell that oftentimes when these things go live. And when 
the activities or entities that are using the systems find that it 
does not provide them the agility and the quality of information 
they need, they themselves will start developing those ad hoc sys- 
tems. 

Mr. Platts. Mr. Weems, it sounds like for those work-arounds 
that you purposely did not write an extension, you really are going 
to be looking to learn from that with CDC for the subsequent im- 
plementation efforts so to try to diminish the number of manual 
work-arounds. 

Mr. Weems. Yes. And in some cases, for instance, the voice rec- 
ognition system that CDC uses, we did not write an extension to 
that. CDC has found that a very useful functionality and it may 
actually be an instance where we want to pick up that functionality 
and look at it for the rest of the department. So, for instance, if 
CDC were to become our bill payer, that functionality would be 
very, very important and that would be the kind of thing that we 
would write an extension for or make sure that meshed with the 
software, because its value at that point, if CDC were our bill 
payer, would be very high. 

Mr. Platts. That is something that will be down the road, that 
decision? 

Mr. Weems. Yes. Yes. 

Mr. Platts. Right. A couple more areas maybe to touch on. One 
is, actually when we were talking about the cost, and I realize that 
you are putting your best estimate out there on the whole cost, but 
one aspect of it is the integration of UFMS with your HIGLAS 
Medicare program. Is that something that is still in the works or 
not included in that estimate of $700 million? 

Mr. Weems. Integration at the reporting level is included at the 
$700 million. The HIGLAS and the UFMS components will be able 
to produce consolidated financial reports within the $700 million 
plan. 

Mr. Platts. As part of the $700 million, it really does include 
how to integrate the two then? I am not sure I am understanding 
you. 
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Mr. Weems. I think it depends on what we mean by integration. 
We will be able to produce integrated reports. They will not be, for 
a number of very good and proper reasons, integrated systems. 
Handling the Medicare workload is just so different both in volume, 
complexity, and just by its very nature is different from a good deal 
of the rest of what HHS does. So we are not going to integrate that 
at the systems level. 

Mr. Platts. OK. So other than reports, you really do not envi- 
sion that level of integration? 

Mr. Weems. That is right. At least at this stage of the tech- 
nology, we do not envision what a layman would call, and I cer- 
tainly consider myself that, a full integration. 

Mr. Platts. Is that a change from the initial memorandum of a 
single HHS system, the original vision? 

Mr. Weems. I think even when this was written we knew that 
the volume and nature of things at CMS would mean that we 
would still need something separate at some level — at the machine 
level, at the code level, some level — where it just would not be fully 
integrated. The Medicare processing workload is immense. It is 
nearly a billion Medicare bills that are processed a year, and that 
is before Part D of the new prescription drug program. 

Mr. Platts. And that is prior to all the baby-boomers retiring, 
right? 

Mr. Weems. That is right. That is before I start submitting my 
bills. [Laughter.] 

Mr. Platts. Mr. Steinhoff, do you have any thoughts about keep- 
ing those systems separate, that being good, bad, or it is hard to 
say at this point? 

Mr. Steinhoff. We really have not looked at that in particular. 
We noted that in pulling the plan together HHS had not stated 
how it was going to integrate those systems. So I think we have 
gotten the answer today. But that is something that we did not 
cover as part of our review. 

Mr. Platts. OK. As we move toward a wrap-up here, we have 
talked about the interaction between GAO and HHS, the GAO re- 
port and its recommendations, 34 specific recommendations I be- 
lieve, 9 that were more pressing, and then some others to work 
through. Maybe you would comment on how those sifted out; the 
ones you have embraced and you already have addressed, ones you 
are addressing, or ones that you disagree on. Is there a consensus 
of how you are going to go forward with those recommendations 
and what you are going to do in response to them? 

Mr. Weems. I think that in HHS we have adopted a good num- 
ber of them, and I think we have informed our friends at GAO of 
those that we have adopted. For others, such as requirements and 
testing, at the time of the engagement GAO’s comments were prop- 
er. But things have changed since then and I think our require- 
ments traceability matrix is much more defined. I think the testing 
that they have been put through reveals that. Also at the time of 
their engagement, we did not have a complete or good test plan. 
I think since that time those things certainly have changed. 

So we, on balance, considered their comments very useful. We 
will continue to work on our management of human capital, for in- 
stance. That is something that was pointed out. Obviously, it had 
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been a concern of ours, but it is something that we need to do. We 
will use clear metrics in defining where we are going, but we are 
still going to continue to keep dates in front of people and to drive 
to those dates while maintaining the quality and integrity of the 
program. 

Mr. Platts. Mr. Steinhoff, maybe if you could address any spe- 
cific recommendations you have made where you have had dialog 
and maybe there is not agreement. Is there one or two or whatever 
number that you think are critical that HHS take a further look 
at? 

Mr. Steinhoff. I think the four things that Keith Rhodes talked 
about up front are really the most important areas now. Testing is 
critical, and testing is driven by the requirements. I am encouraged 
that the requirements issues have been resolved as Mr. Weems 
stated today because they were a concern to us when we were 
there. The question will be how effective has that been. 

Mr. Platts. And on the testing, it sounds like your testing is 
more defined today than when GAO was reviewing. 

Mr. Weems. Absolutely. 

Mr. Steinhoff. There were a number of recommendations made 
in the most recent IV&V report, both that special report Mr. 
Weems mentioned as well as the report the IV&V contractor issued 
on September 10th which covered their August activity. There were 
really a litany of issues surrounding testing and they are a variety 
of important tests. So I think HHS has a roadmap on what to do. 

But it will be very important to assure you have the require- 
ments in hand, and you have the test in a manner that is dis- 
ciplined. It is seeking to find deficiencies because you want testing 
to be as rigorous as you possibly can have it. You want to be able 
to truly pass that test. You want to make sure the system is use- 
able by the user. I read about a system the other day where I guess 
the users started crying when they turned on their computer 
screens. That is the last thing one wants. 

Mr. Platts. Especially after $700 million. 

Mr. Steinhoff. Yes. You are going to have to work really hard, 
as Mr. Rhodes stated, when you get down to the ability to actually 
convert the information you now have to the new system as well 
as integrate with the other 110 systems, in the case of CDC the 
30, and then the metrics are very key. We continue to believe that 
event-driven is the way to go. Our hope is that HHS will have both 
event-and date-driven. Have a date in front of people but assure 
that things have moved through certain events successfully and 
have the metrics to show that. Because we feel without that the 
risk is very, very high. And none of us want to be here in 2007 re- 
visiting this. 

Mr. Platts. We want to be here celebrating. 

Mr. Weems. That is right. 

Mr. Platts. Mr. Rhodes. 

Mr. Rhodes. I would just echo Mr. Steinhoff s points of what we 
consider key to their success. Just taking one example of the inter- 
faces, for example, it is not the number, it is that as we have seen 
at HHS, which we have seen at DoD, which we have seen at 
NASA, which we have seen at Bureau of Indian Affairs and De- 
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partment of Interior, the systems to which they are trying to inter- 
face are not necessarily well-defined in and of themselves. 

And so trying to figure out what that interface is both at a data 
level, at a process level, and then at the actual physical, electrical 
level is very complicated. That is extremely important because that 
is going to be their data source and that is really the pathway they 
move to the transformation that the Secretary and Mr. Weems are 
talking about. As long as the requirement leads to the test and it 
is being measured, they will be able to get there. But that is the 
challenge for them. 

Mr. Platts. I think your feedback certainly has been well re- 
viewed and is being weighed in good faith by the department. With 
Government in general, the joke sometimes is, I am from the Gov- 
ernment, I am here to help. I imagine the departments sometimes 
view GAO that way, we are from GAO and we are here really to 
help, there is some skepticism. I hope that is not the case here be- 
cause I think there is a wealth of knowledge and good faith effort 
to help HHS to be part of the team of this transformation. 

The one thing I would add, and I think, Mr. Weems, you appre- 
ciate it, is that Mr. Steinhoff and Mr. Rhodes personally and GAO 
in a broad sense has a wealth of knowledge and historical perspec- 
tive with other agencies and departments who have gone through 
similar efforts. The counsel they are sharing is not biased on just 
some theory, but based on real practices, experiences elsewhere. So 
I appreciate you and your staff in your efforts in giving great 
weight to their input. 

Thank you all for your great insights today and for helping to 
better educate this lay person on where we stand. I want to thank 
you each individually for your work and please convey to your re- 
spective staffs back in your offices my sincere thanks for theirs. 

I think being a public servant is a very admirable profession. 
Earlier this week I had the pleasure of recognizing a postal service 
employee in my district, in Gettysburg, in fact, who, after 30 years 
of service and 1 million miles of safe driving delivering mail, was 
recognized and welcomed into the Million Mile Club. As one who 
commutes daily, drives about 30,000 miles a year in my commute 
from my district I think, I have to be here 33 years to catch up. 
[Laughter.] 

But as I commended him, I commend each of you and your staffs 
for your work. We know you are truly looking out for the best inter- 
est of your fellow citizens, especially in important areas like NIH 
and GDC, and Medicare, because I want it to be there too when 
I get there. 

I look forward to our committee and staff continuing to work 
with your offices as we move forward in this truly great vision that 
we want to become a reality. And I certainly thank committee staff 
on both sides for their legwork and also helping to educate and pre- 
pare this lay person. So, thanks for your testimony. We will keep 
the record open for 2 weeks for any additional information that 
needs to be shared. 

This hearing stands adjourned. 

[Whereupon, at 3:45 p.m., the committee was adjourned.] 
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